Date: Fri, 15 Dec 2006 02:30:12 GMT From: Axel Gonzalez <loox@e-shell.net> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/106703: [PATCH] vn_stat() fails with files > 2Gb on msdosfs (non 386) Message-ID: <200612150230.kBF2UCmg060380@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/106703; it has been noted by GNATS. From: Axel Gonzalez <loox@e-shell.net> To: Tom Rhodes <trhodes@freebsd.org> Cc: Remko Lodder <remko@elvandar.org>, freebsd-gnats-submit@freebsd.org Subject: Re: kern/106703: [PATCH] vn_stat() fails with files > 2Gb on msdosfs (non 386) Date: Thu, 14 Dec 2006 20:21:16 -0600 > > One thing that crosses my mind is that (in my believing) the maximum > > size of a file under msdos(fs) was 2gb, which could explain this > > "problem" you are seeing. If that is still accurate, msdosfs_vnops.c:#define DOS_FILESIZE_MAX 0xffffffff (4294967295) = 2^32 -1 cp works ok, after patching my kernel, the file is correct (md5 match). > > Hmm, that is an interesting problem, and I'm digging the fix. > FAT32 should handle file sizes up to (2^32)-1 bytes (one byte > fewer than four gigabytes. So we should properly handle this > for all FAT32 file systems. I traced the problem down to the getulong() macro (non 386 version). Problem is not with handling of the file, clusters, dirs. Just that msdosfs_getattr() reports an incorrect (signed) size, and it makes vn_stat() fail. If it helps, more info: MAX_OFF:9223372036854775807 (max size of any file) size of the file: Correct (ufs): 3015487488 0xB3BCB000 msdosfs_getattr(): reported by w/o patch: 18446744072430071808 0xFFFFFFFEB3BCB000 (this is why it returns EOVERFLOW) reported with patch: 3015487488 0xB3BCB000
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200612150230.kBF2UCmg060380>