Looking into every mount point for .Trash directories is not a bug.
Looking is the only way to see if there are contents there that should
be displayed in the system trash can! (As Sebastien notes, the trash
can is shown as the union of all the per-filesystem trashcans, so the
only way to ensure all trash contents are displayed correctly is by
checking each mount point.)
b) and c) are certainly bugs, I agree. unfortunately, b) may be an
inherent conflict between how gvfsd-trash and autofs work; gvfsd-trash
uses inotify to monitor the trash can, which means the reference count
on the mount point never drops to zero and autofs doesn't unmount. c)
should be straightforward to fix.
d) is very odd indeed. Does running "ls /home" have this same effect?
The last time I used autofs this was not the case, so I wonder what's
happening to cause this.
** Changed in: gvfs (Ubuntu Hardy)
Importance: Undecided => High
Assignee: (unassigned) => Ubuntu Desktop Bugs (desktop-bugs)
Status: New => Triaged
Target: None => ubuntu-8.04.1
** Changed in: gvfs (Ubuntu Intrepid)
Target: ubuntu-8.04.1 => None
--
try to access a .Trash-$USER directory on autofs mounts
https://bugs.launchpad.net/bugs/210468
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
