GNU Core Utilities - Bugs: bug #25538, excluded files are still stat()ed
You are not allowed to post comments on this tracker with your current authentication level.
bug #25538: excluded files are still stat()ed
Submitter: | Kevin Pulo <devkev> | ||
Submitted: | Tue 10 Feb 2009 04:24:35 AM UTC | ||
Category: | None | Severity: | 3 - Normal |
Item Group: | None | Status: | None |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Open |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
Carbon-Copy List
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
No changes have been made to this item
My problem is that files I have excluded from du using -X or --exclude still have stat() run on them. In particular, this is a problem when trying to exclude some fuse filesystems on Linux, eg. sshfs and encfs, which deny all access to other users (including root).
For example:
The non-zero exit status is particularly troubling, since it means I cannot chain other commands after du using '&&' whenever it's operating on a tree that has these sorts of fuse fs's in it.
The only workaround at the moment is to exclude the parent directory, eg. --exclude=~kev/mnt/sf in the example above. This unfortunately means that everything else in that directory is also excluded.
Having looked at the code, I'm not sure how this would best be fixed. The list of excluded files is only used in process_file(), which is too late. I presume that the stat() is happening inside fts_read(), which populates end->fts_statp with the results of the stat() call. I suppose that extending fts_read() to also respect the exclusion list would be fairly invasive. Alternatively, the EPERM could persist during the fts_read(), but then be somehow "forgotten about" later for excluded files, allowing the exit status to return to being 0 (assuming no other genuine errors).