GNOME Bugzilla – Bug 157076
ftw()-like API would be useful
Last modified: 2018-05-24 10:33:39 UTC
It would be useful to add ftw()-like functionality to GLib, for systems without ftw() or nftw(). It would call the callback function with the file name in the GLib file name encoding. I think it should be possible, to write a portable thread-safe ftw() workalike using just the GLib API?
Created attachment 33414 [details] [review] Suggested implementation First draft. Open to debate. Doesn't actually obey the don't follow symlinks or don't cross mount point flags yet.
Created attachment 33657 [details] [review] Slight improvements
Created attachment 65907 [details] [review] New attempt, with follow symlink Slightly changed patch, with the stat_buf overridden on non-win32 and in case G_FTW_FLAG_FOLLOW_SYMLINKS wasn't found inside the flags; the logic might be reversed by using lstat() by default. I'm not sure how Tor wanted G_FTW_FLAG_CROSS_MOUNTPOINTS to be implemented: only for symlinks, by checking st_dev?
Shouldn't you call lstat() first, and then if st_mode has S_IFLNK and G_FTW_FLAG_FOLLOW_SYMLINKS is on, call stat()? stat() will never return a st_mode with S_IFLNK on, will it? I don't recall right now how mountpoints should be handled in the code; but my idea was that without that flag, the function would not descend into mounted filesystems. Or would it be more useful to have it the other way around, having to specify a flag in order not to cross mountpoints?
Now that gtk+ trunk wants to use ftw() if available, maybe it would be a good idea to get this into glib and have gtk+ use this instead? But the code in the attachments is just a rough first suggestion, more discussion about what features are needed and what are not would be good. For instance, does it make sense to have nonportable "uid" and "gid" fields in the GFTWEntryStatus struct? (Firstly, there are no simple integer uids and gids on Win32 (but SIDs whish are variable length structures), and secondly, file permission on Win32 isn't based on any POSIXish mode bits, owner and group anyway, but on ACLs. Thirdly, ctime is POSIX-specific too. So maybe just keep size, nlink, mtime and atime.) Should GFTWEntryStatus be renamed to something more generic (GFileInformation?) and be used by a g_get_file_information() function as well? The current g_stat() wrapper suffers from the problem that on Win32 it uses the plain struct stat with 32-bit size field. (There is a function stati64() and struct _stati64 in the Microsoft C library to get large file aware information. But we can't change g_stat() to start using those now, that would break ABI and API.)
(In reply to comment #5) > Now that gtk+ trunk wants to use ftw() if available, maybe it would be a good > idea to get this into glib and have gtk+ use this instead? definitely. the search capability in the file chooser landed from bug #344785 uses a ftw() based search engine object as a fallback, and it seems that it's not entirely portable across unices or other unix-based OS.
agreed
Created attachment 106770 [details] A spinnable file tree walker An alternate file tree walker (that doesn't even attempt to be compatible with ftw) that was comes from an experimental content search system. It needs some rework like using g_build_path instead of sprintfs for portability. The API is spinable and thus will not depend on threads like a recursive file tree walker will, for reentrancy the code probably needs the state to be encapsulated in a struct. Relicensed from GPL3+ to LGPL2+ to allow rework and integration into glib.
-- 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/25.