FileBot

If I use a command similar to the following:
Then xattr attributes like `user.net.filebot.metadata` are not written. If I use something like `--action symlink` they're updated for all affected files. I think it's a bug. Now I need workarounds to make filebot update xattr metadata. Filebot version is 4.8.5 (r6224).

Indeed, xattr & history only works for standard file actions. If you pass in your own script then anything can happen, do nothing, do things remotely, do many many different things, so FileBot can't really perform it's standard actions because it doesn't know what you're doing.

If you pass in a Groovy closure as custom action, then you can return a File object, which is then used for xattr & history just like the standard rename actions:

Sorry, I'm not sure I understand that Groovy code in the action. What is a, b and why do I return File(b) (why not File(a))? Could you please give me the exact Groovy code that makes the xattr update work and I can just copy-paste it? Thanks.

No, because it's your Groovy code that does what you want to do.


Your Groovy Action is expected to be a Groovy Closure that accepts 2 parameters, each of type File, and return the final destination path, again a File object.


e.g. maybe it's more readable like this. Here we do nothing, except create an empty file at the destination path:
--action /bin/true doesn't do anything, so this Groovy code doesn't exactly do that, because it needs to at least create a file, for which xattr can then be written.

I think I'll use my workaround for now. Your examples outright fail and I don't intend to dig deep into Groovy and the filebot API for such a simple function that otherwise works, except for custom user functions. It does the bulk of the work nicely, eg. finding files in online databases, thanks for that.

BTW the custom action's role is exactly as you say, to do nothing, since this pass only runs to gather metadata into xattrs.

I'm still not quite sure what you're doing. --action /bin/true doesn't do anything. Is this intended? Are you doing something different in your actual setup?

If you want to move / copy / etc files, then it's best to use the standard actions, and if you want to call your own tools on newly processed files, then maybe the -exec options is more suitable this kind of post-processing.

Yes, it's intentional. This filebot pass is only to fill xattr metadata. I do 2 more passes on my files to accommodate my file hierarchy/structure.

Since xattr is written to the destination file, xattr can't be written if there is no destination file.

I guess by using --action symlink you can trick FileBot into writing xattr to the original file, via writing xattr to the destination symlink, which links to the original.

rednoah wrote: ↑20 Apr 2019, 18:39 I guess by using --action symlink you can trick FileBot into writing xattr to the original file, via writing xattr to the destination symlink, which links to the original.

Yes, that's my current workaround. I need to clean up symlinks made to a temp dir, though, but that's not a problem.

Could you please point me to the docs for -exec? I can't find it and it's not here: https://www.filebot.net/cli.html

Now that I understand your use case, I can give you a solution: This will do nothing, and trick FileBot into thinking that the original file path is the destination file path, which is then xattr tagged.


You might get a strange history though. I just got no history entry at all in my test case though. IDK.

rednoah wrote: ↑20 Apr 2019, 18:44 Now that I understand your use case, I can give you a solution:

Code: Select all

--action "{ a, b -> a }"

Sorry for not giving enough details. This simple solution works, thanks! I disabled the symlinking workaround.

And sorry for the nag, but is there docs available for -exec somewhere?

Just via filebot -help: Think find -exec. Works more or less the same, except with FileBot format expressions.

Add this to your command and play with it: Here's another example: viewtopic.php?f=4&t=5047

Ah, I see. The built-in help text isn't saying much about how it works and when it's called during a command, etc, I think the find analogy sheds enough light on it.