4 GB file limit? (WAS gzip from ports vs gzip from system)

[Norberto Meijome]

to recap:
dump | gzip > nfs_share_on_w2k_NAS_running_ServicesForUnix

This works fine until the size of the file created on the nfs_share is 
just under 4 GB (originally thought 2 GB problem)

Client : FBSD 4.11, cvsuped April 15th 05, world + kernel.
Server : Win2K-Storage server, SP4, Microsoft Windows Services for UNIX 
3.5  [8.0.1969.1]

more below

Dan Nelson wrote:
>>Norberto Meijome wrote:
>>
>>  DUMP: 66.60% done, finished in 1:32
>>
>>gzip: stdout: File too large
>>  DUMP: Broken pipe
>>  DUMP: The ENTIRE dump is aborted.
> 
> 
> That looks like whatever filesystem gzip was writing to couldn't handle
> files over 2gb.  You mentioned writing to a remote filesystem using
> amd, but it defaults to NFSv3.  Were you maybe writing to a FAT fs on
> the remote end?  You can also see whether amd actually mounted the
> remote fs with NFSv2 by uncommenting the "/var/log/all.log" line in
> /etc/syslog.con, touching /var/log/all.log, and restarting syslog. 
> Then have amd remount the remote system and check the log.
> 
Hmm. ok, as suspected gzip v1.3.5 from ports fails as the other one. And 
the filesize it died on is 4,294,950,912 bytes . Just under 4 GB - 16K 
less than 4 GB. (back to system gzip of course :) )

The native FS on the NAS is NTFS, which doesnt have this kind of 
limitation , as per the following article from MS(may wrap)

http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/Windows/XP/all/reskit/en-us/prkc_fil_tdrn.asp 


I just checked from the server itself with dd from SFU, can create a 5 
GB file with no probs.
dd if=/dev/zero of=/dev/fs/E/temp/test1 bs=4096 count=1310720

So i've stopped amd, bounced box clean, mounted the share via NFS3

mount_nfs -3 edsac:/diablo_backs/ /mnt/test1/

still running this next pass...
any ideas what is breaking...and why?

thanks!!
Beto