Re: Proposition for platform maximum filename/pathname length symbols

[Tor Lillqvist <tml iki fi>]

Chris Morrison writes:
 > Has anyone else been frustrated by the absence of such symbols or have I
 > missed something?

There is no single maximum length of a path name or path name
component that would be valid for all machines on which the binaries
corresponding so a certain GLib header distribution could be
installed. (Consider mounting "foreign" network file systems/shares,
etc.)

The limits can, in general, be different for each individual file
system volume that happens to be mounted on a machine at a certain
time.

What could be added is functionality to determine these limits for a
specified directory.

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.

(Also, the gstdio wrappers should be enhanced to use the \\?\ prefix on
Win32 when necessary, to enable pathnames longer than 260 chars. See
"Naming a File" on MSDN.)

--tml