GNOME Bugzilla – Bug 778798
gio cannot handle files in directories with strlen(realpath(..)) > PATH_MAX
Last modified: 2018-05-24 19:24:18 UTC
Created attachment 346024 [details] Example code which should not fail gio fails to do IO on files whose absolute path is longer than PATH_MAX. By this I do *not* mean that returning the absolute path fails. If you are in a directory that happens to have a long name and create a GFile on "./foo", then reading from this file fails. This should not happen and is a bug. *All* other tools I have at hand manage to handle this situation. I'll attach example code that fails with Error opening file: File name too long: File name too long even though all it attempts to do is to g_file_read() on g_file_new_for_commandline_arg("my-file").
That’s because GLocalFile canonicalises the file path as soon as the GFile is created, which makes the path absolute. This is necessary because it cannot rely on the cwd remaining the same throughout the lifetime of the GFile. I guess this could be fixed by checking if the canonical filename is longer than PATH_MAX before calling g_open() on it in g_local_file_read(). If so, it would have to split the canonical filename into directory components and use dirfd() and openat() to open them in sequence, so that each individual openat() call doesn’t exceed PATH_MAX. This would have to be done for all places in glocalfile.c where a canonical path is passed down to libc. Patches welcome. :-)
Created attachment 346652 [details] [review] Patch to support long filenames in glib's stdio wrapper Thanks for getting back to me. I thought so. Thanks for the hints on an implementation. g_open isn't the only call that needs wrapping, but *any* I/O. I looked into this, and thought that GLib's stdio wrapper might be the best place to implement this. However, things do become quite messy. I'll attach a patch which wraps every libc call with the corresponding __at version as a fallback in case a ENAMETOOLONG happens. You'll see what I mean. The code does what it should, and is quite clean considering what it does (well, except for the helper macro maybe), but it still is a severe reduction in maintainability.
Created attachment 346653 [details] [review] Patch to support long filenames in glib's stdio wrapper
Created attachment 346654 [details] [review] Patch to support long filenames in glib's stdio wrapper
(In reply to Phillip Berndt from comment #2) > Created attachment 346652 [details] [review] [review] > Patch to support long filenames in glib's stdio wrapper Thanks for the patch! > Thanks for getting back to me. I thought so. Thanks for the hints on an > implementation. g_open isn't the only call that needs wrapping, but *any* > I/O. I looked into this, and thought that GLib's stdio wrapper might be the > best place to implement this. I don’t think the stdio wrapper is the right place to implement this, as it then breaks people’s expectations that g_open() behaves exactly like open() — it will no longer return ENAMETOOLONG in some situations. I think glocalfile.c is the right place to do this, as that’s where the path canonicalisation is introduced, and it’s at a higher level of abstraction from g_open(), so we care less about behaving exactly like the underlying libc() call. (The only real reason that g_open() exists is to abstract POSIX differences between platforms like Linux and Windows.) > However, things do become quite messy. I'll attach a patch which wraps every > libc call with the corresponding __at version as a fallback in case a > ENAMETOOLONG happens. You'll see what I mean. The code does what it should, > and is quite clean considering what it does (well, except for the helper > macro maybe), but it still is a severe reduction in maintainability. I think it would be better to move this code into glocalfile.c, and use the same approach to wrap all of its calls to g_open(), g_stat(), etc. IIRC all the relevant calls will be in glocalfile.c. I guess there might be some in the other glocal*.c files.
Created attachment 346669 [details] [review] Patch to support long filenames in GLocalFile Here's a variant that wraps the functions inside GLocalFile. Since paths are passed on to GLocalFileInfo and GLocalFileOutputStream, both are patched to use the wrappers as well. With this patch, I am able to open files in deeply nested directories. Using gedit, I can open, edit and save files. The save file/open file dialog however still shows an error. I've also noticed that some major programs appear to work under the assumption that they can throw the filename reported by GIO against arbitrary other glib functions, especially glib's file utility functions, and hence still cannot handle this case. Nemo (that is, Cinnamon's nautilus fork) is an example.
(In reply to Phillip Berndt from comment #6) > Created attachment 346669 [details] [review] [review] > Patch to support long filenames in GLocalFile > > Here's a variant that wraps the functions inside GLocalFile. Since paths are > passed on to GLocalFileInfo and GLocalFileOutputStream, both are patched to > use the wrappers as well. That looks like a better approach. I’ve got some review comments (mostly relating to following the coding style in the surrounding file), but I think we should get some feedback on the overall approach from a GLib maintainer before any more time is spent on the patch. Matthias, Allison, what do you think about an ENAMETOOLONG handling loop in GLocalFile and friends? > With this patch, I am able to open files in deeply nested directories. Using > gedit, I can open, edit and save files. Great! > The save file/open file dialog however still shows an error. I've also > noticed that some major programs appear to work under the assumption that > they can throw the filename reported by GIO against arbitrary other glib > functions, especially glib's file utility functions, and hence still cannot > handle this case. Nemo (that is, Cinnamon's nautilus fork) is an example. I’m inclined to treat that as a bug in those applications, although the documentation in GLib could be improved (after applying this patch) to point out about ENAMETOOLONG.
When did you actually hit this problem?
just for reference: /usr/include/linux/limits.h:#define PATH_MAX 4096 /* # chars in a path name including nul */
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/1245.