> > What could be added is functionality to determine these limits for a > specified directory. Yes, I think now that this would be a good idea. > > While I have the list's attention, it would be nice to add stat() and > fstat() "wrappers" that would definitely be large file aware on all > platforms. At least on Win32, g_stat() isn't, as it uses the normal > struct stat, not struct stati64, and there is no compile-time macro to > "switch" struct stat to actually mean struct stati64 on Win32. And > even if there was such a macro (like there typically is on Unix, and > which on some Unixes is forced when building GLib-using software), it > couldn't be suddenly forced for all compilations of GLib-using > software, as that would of course break binary compatibility horribly. > > Such wrappers probably should use a struct with the same field names > as struct stat to minimize code changes needed. The st_?time fields > should probably be an as of yet nonexistent sub-second precision GLib > timestamp type, though, and not time_t. > Yes, and the file I/O functions need to be made large file aware on the Win32 port of GLib, as I mentioned in a previous posting. Kind regards, Chris
Attachment:
smime.p7s
Description: S/MIME cryptographic signature