search

kyoheiu / felix

tui file manager with vim-like key mapping
https://kyoheiu.dev/felix/
MIT License
729 stars 26 forks source link

Critical Documentation Issue may #163

Closed theAkito closed 1 year ago

theAkito commented 1 year ago

https://github.com/kyoheiu/felix/issues/161

For this issue I tried to quit the original Felix session.

In the process of trying it, I accidentally renamed a couple of files. Okay, not a big issue. Then I went out of the folder, was hovering over a huge folder full of source code. Since CTRL+C & ESC did not work (and I thought at the time, that CTRL+C was perhaps some special shortcut), I tried to emergency exit out of it by pressing CTRL+D. However, it turned out, that this actually started deleting the entire huge collection of source code I have, at least that's what Felix was telling me. Therefore, I swiftly terminated the entire terminal process to kill the delete operation.

https://github.com/kyoheiu/felix#key-manual

Nowhere in the documentation does it say, that those commands are also activated, when holding the CTRL key. Usually, when holding a control key, like CTRL, ALT, etc. the respective key press does not just emit the original key press, but a combination, which lead me to believe, that any combination with CTRL should be harmless, by default, since it is not mentioned in the documentation.

To fix this issue, the documentation must be updated, or the control character combinations must be fixed, so it reflects the actual key presses. For example, CTRL+d is not just a "d".

I checked the Trash folder. It was empty. Does it mean, the moving to the trash bin process did not finish in time and I could terminate the terminal quickly enough or are there files actually missing now? Since, it's a folder with a significant collection of source code, I cannot just diff it against a week old backup, without getting false positives.

kyoheiu commented 1 year ago

Thank you for pointing this out. As a quick response: The process to delete files occurs at the last stage of the remove command, so if you do not find any in trash dir that should mean that files are not deleted actually.

theAkito commented 1 year ago

As a quick response: The process to delete files occurs at the last stage of the remove command, so if you do not find any in trash dir that should mean that files are not deleted actually.

That's great to hear. It would've been a pain to fix such an issue, if the Trash folder wasn't used.

I remember it saying "Deleting folder...." or something. Then I terminated the terminal.

kyoheiu commented 1 year ago

That indicates the start of file copy to the trash directory. If the copy fails, files are not deleted as well.

Just to be sure, could you delete a test file and see if it is copied to the trash directory?

theAkito commented 1 year ago

Just to be sure, could you delete a test file and see if it is copied to the trash directory?

I deleted the fx.log file and it resulted in ~/.local/share/felix/Trash/1671357511_fx.log being created. I guess, that's correct?

How would the file be restored? Where is the index of where it belongs to, in the original location?

u                 :Undo put/delete/rename.

At least this part of the documentation suggests, that deletion is reversible.

kyoheiu commented 1 year ago

The removed items are stored as path in memory, and you can paste them by p as you can in Vim (that is, d also yanks them as y does). If you terminate this app the information of paths are gone, but in trash directory you still have them. (And unless you :empty it you always have) When you yank & paste the deleted item from the trash directory, the prefix (unix time) is removed and restored as it was.

kyoheiu commented 1 year ago

Released the fixed version. Thank you!