GNOME Bugzilla – Bug 433105
Search stops upon encountering an unreadable directory
Last modified: 2007-07-23 14:10:11 UTC
Please describe the problem: some files aren't found if there is a directory in the hierarchy that isn't readable Steps to reproduce: 1. mkdir ~/tdir 2. chmod a-r ~/tdir 3. ls -l -U 4. search for a file that exists after ~/tdir in the list -or- search for a file that exists in a subdirectory that exists after ~/tdir in the list Actual results: the file is not found Expected results: the file is found Does this happen every time? yes Other information: this may also explain bug #347386 http://bugzilla.gnome.org/show_bug.cgi?id=347386
Created attachment 87486 [details] [review] simple search engine - avoid recursing into unreadable directories may have a negative impact on performance
Created attachment 87487 [details] [review] alternate patch - additional directory visit option adds an additional directory visit option to allow access denied conditions to be ignored. updates the nautilus simple search engine to use the new option.
Hi Marlon, while you wait a proper review from a maintainer, I will give you my 0.02$. I think your second approach is the right one because fixes the root of the problem. I would just add a small enhancement: + if (result == GNOME_VFS_ERROR_ACCESS_DENIED) + if (visit_options & GNOME_VFS_DIRECTORY_VISIT_IGNORE_ACCESS_DENIED) + result = GNOME_VFS_OK; + if (result != GNOME_VFS_OK) stop = TRUE; I would put the first if inside the second because GNOME_VFS_OK is the most common result, so better not add an extra 'if' to check in each loop... something like this: if (result != GNOME_VFS_OK) { if (result == GNOME_VFS_ERROR_ACCESS_DENIED && visit_options & GNOME_VFS_DIRECTORY_VISIT_IGNORE_ACCESS_DENIED) { result = GNOME_VFS_OK; } else { stop = TRUE; } } Thanks for working on this bug...
Created attachment 87616 [details] [review] alternate patch - additional directory visit option updates alternate patch incorporates feedback moves test of the condition closer to the source (detects it sooner)
i've been working on this bug in conjunction with #347386, and i've uncovered another problem (on my system) whereby the directory open function returns an error result (GNOME_VFS_ERROR_NOT_A_DIRECTORY) for a particular entry in /dev/fd (/dev/fd/19 in this case - nautilus shows it as a "link to folder owned" by root). you might find it interesting to "sudo nautilus /dev/fd" and start poking at the entries listed. when i click on "19", it disappears (note: i'm running ubuntu 7.04 - feisty fawn... your mileage may vary). i'm not a linux guru. i suppose there could be a bug in g_stat or g_lstat that is incorrectly identifying the entry as a directory, but i suspect that /dev/fd is somewhat special and the contents may be volatile. the problem can be solved by adding GNOME_VFS_ERROR_NOT_A_DIRECTORY as another result code to be ignored. this raises some interesting questions, though. which return codes from gnome_vfs_directory_open_from_uri() should be flat-out ignored, which ones should be ignorable on request of the client (e.g. nautilus), and which ones should be fatal, causing the directory walk to terminate? what's the appropriate way for clients to identify the return codes to be ignored? a directory visit option for each one? i think i will post these questions on gnome-vfs-list@gnome.org.
Created attachment 87980 [details] [review] additional directory visit option - ignores directory recurse errors i'm done... ship it! :)
commited