Files missing after revert!

[Morf]

I downloaded two new episodes, and renamed them using the right mouse button script.

I then copied these to the folder with the previous 23 episodes in it.

The format of the episode name was not the same, so I loaded the full gui and renamed all 25 files so it was consistent.

I then tried to copy the folder to my NAS and realised I hadn't updated the ini files since the last update so UseExtendedAttributes was enabled, so I edited the ini file and renamed again.

This didn't clear the extended attributes, so I thought I'd revert the last two renames and start again. (Yes, didn't think about it very much, clearly reverting would not remove the extended attributes, would it?)

Selected the two 25 count renames and clicked "revert selection".

I now have a folder with only the two most recent episodes in it, the older 23 are gone. Can't find them anywhere, not in recycle bin or anywhere else on the disk so I'm presuming gone for good.

How can this happen?????? Seriously unhappy.

[rednoah]

No idea. Can you reproduce this behaviour? Does it happen only on remote files or local files as well?

I seem to recall there's some NAS devices with faulty xattr support which may lead to all kinds of strange behaviours. No idea if this is related. I'd log in via ssh and search the entire share for the missing file from the local device (not via smb).

[Morf]

Yes, it seems I can reproduce quite simply... note that this is all on the local disk, no nas involved at all.

Started with a test folder with some files in it which are correctly named.

Open Filebot 4.7, select the folder, match (tvdb). All the files will have a tick next to them showing the names are correct. Nevertheless, hit rename. Message saying (x) files renamed.

Go to history, select the rename operation and hit revert selection and confirm.

Result, one empty folder.

So it's not to do with nas or multiple reverts or anything else, simply reverting a rename when the files already had the correct name.

[Morf]

Looks like this is a 4.7 bug, I have another computer with an older version. On the older version it works fine, updated to 4.7 and it's deleted the files.

If you can point me to an install of an older version I can revert to that version and retest if needed.

[rednoah]

I'll look into that.

There is definitely no delete going on anywhere. Maybe files just got moved to an unexpected location? Relative to the filebot working directory?

@see https://github.com/filebot/filebot/blob ... .java#L138

[Morf]

I can't see any sign of the files anywhere. Certainly not if they've kept their original names (or anything similar), a search doesn't turn them up, and I can't find them in windirstat - bearing in mind there's nearly 10GB gone missing they shouldn't be hard to find!

My coding days date back to Pascal, but looking at the code your first test is if the current file exists and the original doesn't. But in this case, since current and original names are the same, both will exist so this isn't going to work. Not sure what happens then...

Has anything changed in this area in the latest couple of versions? The version on my second machine was from late 2015 and that worked OK, it only stopped working once I updated to the latest version.

Have you been able to reproduce the problem? I've seen it now on two different Windows 10 machines.

[Morf]

Reading the code a little further, I think in these circumstances (current and original are both files and the same) it passes this test:

if (currentAttr.isRegularFile() && originalAttr.isRegularFile())

and therefore executes this code...

Files.delete(current.toPath());
return original;

Which looks to me like it deletes current, then presumably attempts to put original back in place, but since current and original are the same there is no original any more.

Like I say, I really don't understand Java (or anything else from the last 30 years) but....

[rednoah]

So you mean new and old path is exactly the same? Is that possible?

4.7 shouldn't add history entries for files that have been skipped. Could it be that there was old history entries that were reverted with 4.7?

I guess this is a special case that I'll have to have a look at again.

[Morf]

The reason I'm saying new and old path is the same is because although filebot says it's renamed the file, the file names haven't been changed, because they were already correct.

Example:

File is called Garkbit S01E01 - The Waiter.mp4
I lookup this, and filebot's lookup returns a name of Garkbit S01E01 - The Waiter.mp4 (ie the same name). It then puts a tick indicating that the file already has the correct name, but if I hit "rename" then it seems to rename the file.

At this stage I'm guessing that -
Current file is Garkbit S01E01 - The Waiter.mp4
Original file is Garkbit S01E01 - The Waiter.mp4

So if I then hit revert, I'm guessing it deletes the current intending to rename original back, but can't do because original is the same as current!

I'm sure there's more to it than that, I'm just trying to point in the right direction.

[Morf]

BTW, you say "4.7 shouldn't add history entries for files that have been skipped. " The thing is, it **doesn't** skip the files, at least according to the messages, it renames them and it definitely adds a history entry, I can see this from the history timestamps.

[kim]

I can confirm the bug, if same format / filename:
the GUI do make history (you can see it in the GUI), but only writes the file after exit of GUI.

Pressing "Revert" on that history point deletes the file

you can see this if you use e.g.
http://www.nirsoft.net/utils/folder_changes_view.html

<?xml version="1.0" encoding="UTF-8" standalone="true"?>
-<history>
-<sequence date="2016-05-14T23:04:04.915+02:00">
<rename dir="D:\_DoWnLoaD\Done\tv" to="Futurama S01E01 - Space Pilot 3000.mp4" from="Futurama S01E01 - Space Pilot 3000.mp4"/>
</sequence>
</history>

[rednoah]

Fixed.