Some video files now show 0 Bytes?

[fritz84]

I'm using 4.8.5

I ran a scan on my external HDD for a folder that holds my shows. Now, after doing a match and rename...certain shows show as 0 bytes and don't work anymore? What I don't get some shows are fine, while certain shows aren't? I'm pretty pissed. I checked my drive and there's nothing wrong it. Also, I just ran the EXE file.

[rednoah]

FileBot does not modify files, and therefore cannot corrupt files.


What operating system are you using? What file system(s) are you using? Are you using non-standard 3rd party file system drivers? Are you using a NAS with attached HDD accessible via remote file system, or a normal external HDD attached via USB directly to your machine?

[fritz84]

Win 10. No, on the NAS just a external usb to laptop. What do you mean what file systems? Yes, you say it can't corrupt, but the problem happened after the scan?

[fritz84]

I suppose I'll have to run a recovery program to see if that will help.

[rednoah]

FileBot only does "Dear OS: Please Move /A to /B." and then the OS performs the actually operations to make that happen. If the OS, file system drivers, device firmware, etc f*ck up in the process, that is of course a possibility. Though that would be extremely rare on a typical setup, e.g. Windows 10 using NTFS drives. But if you do something strange like using macOS to access NTFS with write access using 3rd party device drivers, then it's not quite so unthinkable.


What file system is your drive formatted with? NTFS? FAT? exFAT? (e.g. screenshots of the disk properties view will tell)


You may to ask a computer-savvy friend to explain these things in detail, as these things are easier explained and demonstrated in person.


My educated guess is that the underlying filesystem f*cks up in response to FileBot setting xattr metadata. Setting xattr does not modify files. But it is a rarely used file system feature, so it may be less well-tested by manufacturers, if there's something unusual about your setup (e.g. using Ext4 on Windows or NTFS on macOS). The logs may give some indication. There's also scripts for viewing and clearing xattr (requires basic command-line skills).

[fritz84]

Win 10

NTFS

Windows

[fritz84]

From searching Xattr is for Mac, but I use a PC. Are all my files lost or what? Thank you.

[rednoah]

1.
Windows 10 / NTFS works flawlessly for countless user. Since FileBot doesn't modify files, I can't imagine a code path where FileBot would truncate files. The code for that just doesn't exist. My best guess is that due to some sort of file system corruption or hardware fault, file size queries return 0 not due to file size actually being 0 physically on disk, but some sort of error:

https://recoverit.wondershare.com/compu ... 0-8-7.html
https://www.youtube.com/watch?v=FF5ksMsidao


2.
xattr or Alternative Data Streams (ADS) are supported by NTFS, and FileBot will use them to store additional metadata:
viewtopic.php?t=324

You could try to clear xattr to see if the existence / non-existance of xattr makes a difference in your case:

Code: Select all

filebot -script fn:xattr --action clear /path/to/files

viewtopic.php?t=5#p5394

[fritz84]

I decided to give a program called Testdisk a try and it's been finding a lot of 0 Byte files whole again. Thanks anyway for the help. I like the idea of Filebot, but too scared to use it again.

[rednoah]

I decided to give a program called Testdisk a try and it's been finding a lot of 0 Byte files whole again. Thanks anyway for the help. I like the idea of Filebot, but too scared to use it again.

That's fine. But be aware, that this is most likely unrelated to FileBot specifically. If it happened once in response to FileBot renaming files, then it may very well happen again in response to some other tool doing some other file system operation. I would not completely trust this particular piece of hardware going forward.


Also, make sure to click "Safely Eject" before physically disconnecting USB drives, just in case.

[Grumbeerto]

Hi there,

i have the same problem ...

i just post-processed my renamed movies (checking foldersizes, multiple formats ...) and i found 10 files that had 0 bytes! I watched most of the movies before, so i know they were not copied empty to the server. while i dont know if that didnt happen before.
but none of the not renamed files have 0bytes, and no other files on the other shared volumes have 0bytes.
i had one program crash while renaming (but i did the whole renaming process in about 20 steps) and the 0byte movies are from different steps (so it cant be crash-related).
I checked the error.log (nothing there). in the history.xml they appear.
can i activate more logging then the above?
or what could i do to track down/prevent the problem next time??
any suggestion on recovery tries?

my system where i run the rename-action by program: win10x64 home (filebot-portable)
the server: syno1815, (SHR)ext4/shared volume (on internal WD-Gold 12TB)

any help welcome!!

[rednoah]

What does the file size say locally (not via SMB remote file system) on the NAS?

i.e. how did you check the file size? On the device? Or remotely from your Desktop via remote folder access?

[Grumbeerto]

all show 0Bytes (windowsexplorer via remote, DSM-Web-Interface, Putty)

[rednoah]

You could try to see if Synology has any logging for remote file system operations.

As far as FileBot is concerned, there's nothing you can do different, either move files, nor not move files, its 1 operation, 1 line of code, and FileBot itself doesn't know (and has no way of knowing) how exactly the underlying platform then decides to perform this operation.

You could try to disable xattr support. xattr-write is the only file system operation other than move. Generally unrelated to file content, but a buggy xattr implementation on the NAS side could lead to undefined strangeness.

0 bytes doesn't necessarily mean file size, instead 0 can indicate the lack of a file size value, i.e. file system corruption.

[Grumbeerto]

any advanced log-options for filebot other than (automatic) errorlog.txt?
i just logged all files with size on the drive, to track down possible future errors.
is disabling xattr only available for cmd-line ops?
will check filesys 2morrow and give feedback.
must shutdown my nas now.

[rednoah]

1.
FileBot has verbose logging, but it won't help in this case, since the move operation is a single operation as far as FileBot is concerned, so FileBot can't possibly provide any insights into that one atomic operation:
viewtopic.php?t=3913

You might get more logging from various Windows components or Synology components that actually make the move operation happen. Google might help. I have no expertise in that regard though.



2.
You can configure FileBot to store xattr data into a plain file structure, instead of native file system xattr:

Code: Select all

filebot -script fn:properties --def net.filebot.xattr.store=.xattr

viewtopic.php?t=324



3.
Comparing 0 byte files with normal files, might give us some hints. You could Google for various Linux tools.

Code: Select all

stat /file/path

Since 0 byte file size values could be bogus, we could also try to read the file, because if 0 byte merely indicates an error, we might still be able to read something:

Code: Select all

cat /file/path | wc -c

Try Google for "0 byte files". You'll get all kinds of results, and perhaps some of them are relevant to your case in some way, or at least give ideas for debugging.