#8 "Trash" function bad for multiple volumes

[smpolymen]

When using delete (for instance to cut files,) vifm moves files to ~/.vifm/Trash. This is bad if the files are on separate filesystems and are not small. For instance, if I wanted to move a file on a file system on disk A, but my home is on disk B, this would require copying it from disk A to disk B and then back to disk A, which may take a long time.

[ken steen]

I am not sure of the best way to fix this problem. It is especially annoying when you are using ssfs over a network and delete a large file.

[xaizek]

There are 2 new commands that should help with this problem:
D - delete file (using "rm")
P - move yanked files (using "mv")

[Sergei Shilovsky]

What about making an option to keep a separate trash on each fs? Or would this require more dependencies?

Some suggestions:

:set trashdir=~/.vifm/Trash - current behaviour

:set trashdir=%r/.Trash - for a separate trash on each filesystem, %r is replaced with fs mountpoint

:set trashdir=%r//.Trash - deleted file %r/path1/path2/file goes to %r/.Trash if %r/ is writable, or to %r/path1 if its writable, or to %r/path1/path2 which is almost always writable as you're able to remove files from there. If neither of those directories is writable, an error message should be shown.

Its gonna be hard for the user to keep eye on all these trashes manually, so at least an option to print all existant (non-empty) trash locations should exist.

[xaizek]

What about making an option to keep a separate trash on each fs?

Actually, I don't remember the reason, which stopped me from doing this, or if there is such reason at all. I need to check email archive, maybe I forgot something important. But in general I don't see any obstacles for having multiple Trash directories.

Or would this require more dependencies?

No, vifm has all that's needed to implement it.

Its gonna be hard for the user to keep eye on all these trashes manually, so at least an option to print all existant (non-empty) trash locations should exist.

Maybe a command like :trash, which, when invoked without arguments, displays a menu with list of trash bins that can be navigated to.

Thank you for the suggestions on this topic, I'll implement this unless there is a real show stopper I forgot about.

[Sergei Shilovsky]

:set trashdir=%r/.Trash
other macros may also be useful. like %u and %U (or vice versa) for user-id and user-name

:trash
maybe, :cdtrash or :trashes, as :trash feels more as a verb for me.

btw, which repo is primary? this one or the one at github.com/ksteen/vifm?

[xaizek]

btw, which repo is primary? this one or the one at github.com/ksteen/vifm?

This one was created before the repo at GitHub, but master branch and tags are updated at the same time for all repositories, so one shouldn't see any difference. I push some temporary branches to GitHub if they are related to discussions there, but other than that there are no differences.

As for where to post issues/tickets, I don't really have any preference. Use whatever is more convenient for you.

[Sergei Shilovsky]

This one may be worth:

The FreeDesktop.org Trash specification
http://freedesktop.org/wiki/Specifications/trash-spec/

[xaizek]

Thanks, I didn't know that such specification exists. It's definitely worth considering it, though I'm not sure whether it's the right thing to support it fully by vifm as it's also used as a temporary storage, not just as a trash. Say you temporary moved 1000 files to the Trash, you'll see all that files in other file managers as well as various "Open/Save file..." dialogs. It doesn't seem to be a problem, but a bit strange behaviour I think.

[Sergei Shilovsky]

I'm not sure whether it's the right thing to support it fully by vifm as it's also used as a temporary storage, not just as a trash.

maybe it's better to be named 'buffer', not 'trash' then, at least at the manual and/or option names?

[xaizek]

Thanks for the suggestion, good point.

It makes sense, but such changes break compatibility with previous versions (if options are renamed) which shouldn't happen in minor version updates, although it might be changed say in 0.8.

[xaizek]

Sergei, if you have time, please check out the trash-dir-per-mount branch at SF repository. With it such setting of 'trashdir' is possible:

set trashdir=%r/.vifm-Trash,$HOME/.vifm/Trash

I'm going to modify :empty command and add :lstrash command (not its final name), but don't want to merge changes related to 'trashdir' into master branch yet, need to test it more.

[Sergei Shilovsky]

Certainly, I'll check it and report any issues. But I would unlikely test it more extensively during the next week or two)

[Sergei Shilovsky]

Well, the only issue I've found so far is a bit confusing error message with these settings:

set trash
set trashdir=%r/.vifm-Trash

when deleting something from /home/user (/home is a mount point and is not writable by the user).

Error message:

Background Process Error
mv: cannot move ‘/home/sh/20-nvidia.conf’ to ‘(null)/000_20-nvidia.conf’: No such file or directory

The rest looks to be fine.

[xaizek]

But I would unlikely test it more extensively during the next week or two.

It's not needed, I just wanted to check that it doesn't do any harm and can be merged into master.

a bit confusing error message

Thank you, I missed this case. Will add a check for it to print much better error message.