Revert option did not have all files (after cancelling operation midway)

[MasterCATZ]

as 4.9.1 seemed to fix a problem I have had with the way files were loaded for the last few years and i was finally able to use filebots gui again, I was so excited I completely forgotten to create my symlinked files first , then I was wondering what was taking the move so long then it clicked to me its was moving the original files pressed cancel 3 files had been moved however the history only knew of 2x files for me to revert , the third-file still existed in the original files menu , but file had been well and truly been deleted from the original location and a new file had been created / allocated and a hash check showed it was 100%, no real biggi I have hourly rolling snapshots just because of my blunders like these

[MasterCATZ]

how ever I broke it again , it seems if you symlink a file while filebot is looking at the folder the symlinks are going to , it then greys out all files again , oh well back to drag and dropping

[rednoah]

You mean the history didn't record some files that were actually processed? Or do you mean that the operation was in the history, but clicking Revert, it didn't work?


What does filebot -script fn:sysinfo say?


What can you tell me about the target file system? Presumably, we're not talking about a local file system?


Rename panel will grey out list items if there is no corresponding item on the other side of the list, which should be fairly unrelated to any particular files or symlinks existing somewhere in some folder.

[MasterCATZ]

https://drive.google.com/open?id=1IfAQ4 ... kEXSFIDrc1

history didn't record some files that were actually processed,
what ever file was being worked on when I cancelled did not get recorded, but it seemed to successfully complete the move before stopping

Files are stored on different arrays , Multimedia is stored using snapraid/mergerfs using btrfs , any program / database / docker / Virtual-machine etc that I have running is on zfs

I had just noticed I was locked out from being able to accesses the files again from the GUI when it was iding where I was symlinking files to , as soon as they updated I was locked out from being able to browse files through the GUI again , no real drama been having to drag and drop for a few years now , just fired up root to see if it still had access to files and its also greyed out ,

I could not replicate the greyed out bug on a virtual-machine so still no idea why it keeps happening on my main install , which is technically only 20 days old as its a fresh 20.04 install with just home folder applied

[rednoah]

1.
I have received your video. You are talking about the File Chooser. If you click on Select Folders, you can only a Select Folders. If you click on Select Files, then you can only select Select Files. So you'll want to click on Select Files, otherwise files will be grayed out as not selectable.


2.
Any kind of issues with the history, file system, etc would be unrelated to that. The above is just a limitation of the native file chooser, which doesn't support choosing both files and folders at the same time.


3.

what ever file was being worked on when I cancelled did not get recorded, but it seemed to successfully complete the move before stopping

It seems that "cancelled" would be an important keyword that probably should have been mentioned right away, don't you think?

Depending on how you "cancel", clicking on Cancel in the progress dialog, and just killing FileBot, that could make a difference.

Depending on your selected Rename action, and underlying OS and filesystem implementation, FileBot may not be able to cancel operations. FileBot can only politely request the underlying operation to be cancelled. I suppose there is room for strange race conditions, especially if exotic file systems are involved.



EDIT:

I've reviewed the code. If the rename action succeeds, then an entry will be added to the history, and items in the GUI will be removed based on that. If an item is not removed from the GUI, then FileBot thinks the rename action failed, which means underlying platform reported a failure, so not much we can do about that if that's not actually the case. If debug logging is enabled, then there might be relevant logging.

[MasterCATZ]

cancelled through filebot's dialogue

thanks for looking,
another thing might be for files to not be deleted until the task is completed instead of going down the process list when moving / copying files to different locations , tho I guess it would be hard for it to determine if its going to another filesystem or not

TBH I could not be bothered looking for which mergerfs drive contained the file to revert the snapshot from as I still had the torrent to compare the hash I just moved it back / renamed

looks like this version handles v2 names a lot better than in the past it used to get confused thinking they were seasons

and how can I disable the dark theme and go back to the old style ?
it looks like your right I seem to be clicking on the folder option instead of files

[rednoah]

1.
FileBot doesn't delete files. But the OS might implicitly delete files when performing a move operation. So not much we can do there.

You can use a custom shell script as --action though, then everything is completely up to you:
viewtopic.php?t=4915


2.
01v2 episodes shouldn't bother FileBot. That has been supported for years. Just post the logs if something doesn't work.


3.
You can switch to the System theme like so:

Code: Select all

filebot -script fn:properties --def net.filebot.theme=System

viewtopic.php?t=9827