Re: Determine if a file system supports files > 4GB
Re: Determine if a file system supports files > 4GB
- Subject: Re: Determine if a file system supports files > 4GB
- From: Phil Jordan <email@hidden>
- Date: Tue, 13 Aug 2013 12:19:28 +0200
On Tue, Aug 13, 2013 at 2:47 AM, Dragan Milić
<email@hidden> wrote:
On pon 12.08.2013., at 22.22, Phil Jordan wrote:
> Have you tried what happens on ftruncate() to the desired file size on such file systems? Granted, that might actually write 4GB of zeroes to the disk before you get a chance to fill it with real data, which might slow things down and unnecessarily stress the hardware as FAT32 also doesn't support sparse files.
Pretty much the same: FAT32 over cable: errno=EFBIG. FAT32 over SMB: errno=EINVAL.
getattrlist()/VOL_CAP_FMT_2TB_FILESIZE approach gives the same results: says the capability attribute is valid in both cases, for FAT32 over cable the VOL_CAP_FMT_2TB_FILESIZE bit is not set, but it is of FAT32 over SMB. I kind of expected it. Like Jim has said, there's not much one can do about network file systems that don't or can't expose the limitations of the file systems on the server.
I guess at least ftruncate() will save you actually copying the first 4GB across. If ftruncate to 0 works and ftruncate to the file's size gives EINVAL, then I guess you can special-case that to assume the size isn't supported… The only problem I see is when ftruncate() succeeds on a filesystem that doesn't support sparse files and has to write zeroes.
phil
--
http://philjordan.eu/ - Phil Jordan, software development contractor
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden