operation on unexpected file

[muellerto]

If you have a file selected and the cursor is on another file it can happen that file operations happen on the unexcepted file.

I had a directory and files in that directory. And the cursor was on a file of that directory. But the directory himself was selected (with <space>) by a previous selection. When I used <delete> lf tried to delete the directory, not the file where the cursor was on, and failed because "another process" was on that directory, meaning himself.

In my opinion the problem is that lf allows having a selection after a directory change - ranger does strictly not. If the user has a selection and then he changes the directory the selection should not be valid for any operation in the new directory except for <paste>.

[gokcehan]

@muellerto I understand your frustration but you may as well consider this as a feature. There are cases when you want to select and operate on files in different directories in which case ranger's model falls short. If you are worried, you can always run unmark before you execute a command in the current file to make sure you don't have anything marked. If I may ask, why would you mark a file in the first place if you were not going to do anything with it?

In order to avoid such issues, maybe we can add something to the ui to show the number of current marked files.

[muellerto]

If I may ask, why would you mark a file in the first place if you were not going to do anything with it?

There's no Why in the meaning of a concrete intention. This mark was just a left over from a previous operation. I had this mark and changed the directory and this mark survived, even for copy, cut or delete operations. This was unexpected for me and I must really think about what this should be useful for.

Look, having things you can't remember just happens. Sometimes you have a window with a process open all the day, whenever you need it you bring it into foreground and then you have a concrete situation you not always know in all details. I never had this in ranger, ranger uses existing marks from other directories consequently for yanking (pasting) only, for nothing else.

[gokcehan]

@muellerto I'm just asking because you might have experienced a bug to trigger this, maybe one of the copying bugs on windows. Normally we expect to have no leftover marked files on regular use. For example. copy and cut operations unselect files on success.

I think also part of the fault is that our delete prompt is only rudimentary. We have only added the prompting mechanism recently and I haven't got a chance to improve it. I think it would be better to add the names of files and directories to the deletion prompt to minimize such accidents in addition to having an indicator in the ui for visual selection.

[muellerto]

@muellerto I'm just asking because you might have experienced a bug to trigger this, maybe one of the copying bugs on windows. Normally we expect to have no leftover marked files on regular use. For example. copy and cut operations unselect files on success.

The scenario is easy: Mark some files with <space>, forget why :), and then change the directory, perhaps multiple times, and navigate onto a file or subdirectory. When you now do a delete operation lf consequently deletes the previous (outer!) selection, even if you haven't seen this for hours.

I think also part of the fault is that our delete prompt is only rudimentary.

Yes, I also thought this. In that moment when you get this prompt you should confirm something while you are sometimes not sure anymore. If you have one or two files in the selection you should name them, if it's more you should at least show a number or so.

[gokcehan]

I have now added colored count numbers of selected/saved files to the status line which should make things more obvious.