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
