Re: Re: Can not copy files >=4GB. Leopard (for NFS)
Re: Re: Can not copy files >=4GB. Leopard (for NFS)
- Subject: Re: Re: Can not copy files >=4GB. Leopard (for NFS)
- From: Mike Mackovitch <email@hidden>
- Date: Tue, 1 Apr 2008 11:55:06 -0700
On Tue, Apr 01, 2008 at 11:16:27AM -0700, Doug Rudoff wrote:
>
> The one NFS server not originally tested was a Mac OS X Server. And
> with that, files larger than 4Gb _can_ be copied with the
> Finder. Looks like Apple skipped the testing on non-Mac NFS servers.
Apple DOES test against non-MacOSX NFS servers. But apparently the
copying of files *using the Finder* wasn't as extensively tested.
> I compared the NFS pcaps between a 10.4 X Server and a FreeBSD
> server. The difference? The X Server's reply to an NFS FSINFO message
> sets maxfilesize to UINT64_MAX (0xffffffffffffffff = 16 exabytes),
> which is a completely invalid value.
>
> I modified the nfs server code in the kernel I'm using to use
> UINT64_MAX as maxfilesize as well. And now ... the Finder can copy
> files more than 4Gb from a 10.5.2 client to my NFS server.
>
> So, as long as you're willing to modify your kernel, there is a
> workaround. The side effect is that the client thinks it can send
> files that exceed the NFS server's capabilities.
>
> This is caused by two bugs on Apple's part:
> 1) The X Server NFS server returns an invalid maxfilesize.
> 2) 10.5.2's NFS client code will only allow files more than 4Gb to be
> transferred if the NFS server's reports its maxfilesize as UINT64_max.
Just to be clear... it's NOT the NFS client code that is disallowing the copy.
If it was, then copies would not work from the command line either. It's
the Finder (and/or the frameworks it uses) that is disallowing the copy because
it is checking the following volume capability (taken from getattrlist(2)):
VOL_CAP_FMT_2TB_FILESIZE If this bit is set the volume format
supports file sizes upto 2TB. This bit
does not necessarily mean that the file
system does not support file size more
than 2TB. This bit does not mean that
the currently available space on the
volume is 2TB.
Introduced with Darwin 8.0 (Mac OS X
version 10.4).
The NFS client in 10.5 was programmatically setting this based on whether the
NFS server reported a maximum file size of 2TB or greater. Makes sense, no?
Unfortunately, that capability is not used for what it's documented as being.
Instead that capability is being used (by the Finder) as an indication
of "large file support" (aka the support of files larger than 4GB).
In the end, the fix is in the NFS client code because it needs to be changed
to report the value of that capability NOT as it is named/documented, but
rather how it is used.
> Macko's previous reply indicates that Apple is aware of bug #2 and is
> in the process of fixing it for a later release.
Oh, and your "bug #1" isn't a bug. The NFSv3 FSINFO.maxfilesize value is
an unsigned 64-bit value. UINT64_MAX is a valid unsigned 64-bit value.
HTH
--macko
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden