Hello!

I'm having some trouble with using Nautilus' trash function on my use case:

I have a server with several mount points. Each of these has a
'.Trash' folder in its root, with 1777 permissions. On my desktop
computer, I'd like to access the contents of the server via network
mounts. If I make a network mount for each mountpoint on the server,
trash works correctly. However, if I network-mount only the root of
the server, trash works only for files on the server's root
filesystem. Since I have many filesystems, which change relatively
often, I'd rather do it this way than mount each FS individually. I'm
using SSHFS and AFUSE, though in principle my problem would manifest
for every kind of network mount.

AFAIK, Nautilus currently works like this: for each filesystem on the
machine where Nautilus runs, it searches the root for a '.Trash'
folder with 1777 permissions; every file deleted on that filesystem is
moved to a sub-folder of .Trash, created for the current user. The
move obviously fails in my case, since files like
~/global-mount-point/mnt/server-mount-point/file are on a different
file system (on the server) than ~/global-mount-point/.Trash, but
Nautiles can't see that.

I'm wondering if the algorithm couldn't be changed for the following:

a) when a file is trashed
b) try the current algorithm; it if succeeds, done; if it fails for
any reason, then:
c) for each folder in the path starting with the file's mountpoint,
and ending with the file's parent:
d) check if it contains a suitable .Trash folder and if so try to use
that; if that fails, continue with the next folder in the chain.
e) if trashing works at some point, add that .Trash folder to
Nautilus' “database” for all files below its root.

(Note that even after step (e), files deeper than the one just trashed
might still be on other filesystems, and this will be discovered
later.)

I've just read http://freedesktop.org/wiki/Specifications/trash-spec
but I can't tell if this proposal would directly conflict with the
spec. It seems to make some allowances for filesystems that work
differently than expected, but I'm not sure how many. Even if it does,
the spec's not final, and it might be modified to allow it.

The main problem I see with my proposal is that discovery is done on a
case-by-case basis (we can't just walk the entire filesystem looking
for .Trash directories), and the Trash view won't show such files
until after a .Trash folder is found. A partial solution is that
Nautilus should keep a list of all .Trash folders it encountered, and
try to display their contents if they exist. It's important not to
remove folders from this list when it can't find them: they might be
on a mount-point that's not yet mounted; instead, it should keep them
for a while (say, a year since the last time they were used).

It seems a bit complicated, but AFAIK there's no other solution for
this kind of situation, at the moment. And since FUSE and other
complex filesystems are getting more popular, it'd be good to have a
solution available.

What does everyone think?

-- Bogdan Butnaru
--
nautilus-list mailing list
nautilus-list@gnome.org
http://mail.gnome.org/mailman/listinfo/nautilus-list

Reply via email to