site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com User-agent: Mutt/1.5.17 (2007-11-01) 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 (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com