Updating xattr tags when file name and location does not change

[CybeleAttis]

Hi,

Previously I was able to use the Filebot UI to tag files with xattr data even if the file itself was not being renamed or moved. This was useful as I sometimes re-encode and replace certain files in my library, which leaves them in the original location and with the original name, just lacking the xattr data. Since the most recent update, Filebot seems to just ignore files that don't need a name or location update. Is there any way to restore this functionality?

Thank you,

[rednoah]

I'm not aware of any recent changes.


What does the log say? What does sysinfo say? What is the target file system? Please click on the link in my signature.


Did you run tests on the local file system where xattr are definitely supported to confirm the issue?

[CybeleAttis]

Code: Select all

----------------------------
FileBot 5.1.2 (r10125)
JNA Native: 6.1.6
MediaInfo: 23.10
7-Zip-JBinding: 16.02
Tools: fpcalc/1.5.0
Extended Attributes: OK
Unicode Filesystem: OK
Script Bundle: 2023-11-06 (r952)
Groovy: 4.0.15
JRE: OpenJDK Runtime Environment 17.0.8
JVM: OpenJDK 64-Bit Server VM
CPU/MEM: 16 Core / 17 GB Max Memory / 1.8 GB Used Memory
OS: Windows 10 (amd64)
STORAGE: NTFS [(C:)] @ 1.8 TB | NTFS [(D:)] @ 1.4 TB | NTFS [Caim] @ 998 GB | NTFS [] @ 1.9 TB | NTFS [] @ 5 TB | NTFS [] @ 9 TB | NTFS [] @ 14 TB | NTFS [] @ 3.2 TB | NTFS [] @ 5 TB | NTFS [] @ 4.6 TB | NTFS [] @ 11 TB | NTFS [] @ 2.9 TB | NTFS [] @ 11 TB
DATA: C:\Users\CCC\AppData\Roaming\FileBot
Package: MSI
License: FileBot License PX31387384 (Valid-Until: 2071-12-06)
-------------------------------

File System is NTFS and previously it did work to the destination drive in question, an example of the issue is here:



The first file will be renamed successfully, as I have edited the filename so it will be reprocessed by Filebot, but the second file will not, and will remain unprocessed in the UI:



Note that this only happens for files that are identical in location and name to the destination. If I move these files out to the main folder, I get the normal filepath:



I mention this because the behaviour of suppressing the filepath when the file is already in the destination folder seems to be a new behaviour, as is the file remaining in the UI after running rename if the filename is identical (green arrow).

Logs do not show an error.

[rednoah]

Thanks for the screenshots. The no-op file remaining in the UI is unusual. I will look into it.

New Names trying to display shorter relative paths instead of longer absolute paths if possible is indeed new behavior. This change is purely visual though.

[rednoah]

I was not able to immediately reproduce the issue on Windows on either local NTFS drive nor remote SMB network share with the portable edition. The issue is likely specific to the MSI installer package which uses native Windows File Dialog integration.


You can disable Windows File Dialog integration by running the following command:

Shell: Select all

filebot -script fn:properties --def useNativeShell=false

[CybeleAttis]

That worked!

Thanks as always for the quick support!

[rednoah]

FileBot r10161 fixes the issue.