RE: Proposition for platform maximum filename/pathname lengthsymbols
> > 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 smime.p7s Description: S/MIME cryptographic signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Proposition for platform maximum filename/pathname length symbols
Hi all, I would like to make a suggestion for a small but useful addition GLib, which I think is a glaring omission and which I have found myself needing for a current development project. I propose that the following symbols be defined and available to programs compiled against GLib: G_MAX_PATH_LENGTH G_MAX_FILENAME_LENGTH The purpose of these should be self-explanatory; G_MAX_PATH_LENGTH would be defined as the maximum length in bytes a pathname can be (e.g. PATH_MAX under Linux and MAX_PATH under Windoze). G_MAX_FILENAME_LENGTH would be the maximum length of a single filename (if different). Has anyone else been frustrated by the absence of such symbols or have I missed something? Regards, Chris smime.p7s Description: S/MIME cryptographic signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GLib Bug: IO Channel cannot work with files larger that 2GB
Hi all,
There seems to be a bug with the IO Channel functions in Glib version 2.8.4
for Windows. This bug prevents seeking in files greater than 2GB in size,
i.e. where a 64-bit file pointer would be required.
The following snip of code will work if 'file_channel' refers to a file of
less than 2GB in size, however for a larger file, say 8GB the call to
g_io_channel_seek_position() will fail and gerror will contain
G_IO_CHANNEL_ERROR_INVAL.
GError *gerror = NULL;
gint64 seek_offset = -22;
if (g_io_channel_seek_position(file_channel, seek_offset, G_SEEK_END,
&gerror) != G_IO_STATUS_NORMAL)
{
crash_and_burn();
}
Is this a known bug/issue or am I missing something?
Regards,
Chris
smime.p7s
Description: S/MIME cryptographic signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
