Hi, it seems, that if directory in the write node does not exist, no file were written.
That should be an option (Check for “Create if not exists”?) on the write file node. I made a workaround with an shell script that creates the directories on preflight, but its not optimal to change also the shellscript, when directories get added or changed…
Retrobatch should be creating the folder if it isn’t there, and for most cases it does.
However, I did manage to create an instance where if you launch RB with the folder around, then you delete it via the terminal, and try and run the workflow, the folder will fail to be created. I believe I’ve got a quick workaround for this though. If you get a chance, could you try the latest build and let me know how it works for you? You can grab it from the following URL: https://flyingmeat.com/download/latest/#retrobatch
thanks,
-gus
Hi Gus,
downloaded lates update and tried, but when deleting the folders in the output folder, retrobatch writes the files to the folder in trash rather than generating new folders…
…even after emptying trash, the files get generated in the trash folder.
and a strange number gets added to the folder names, e.G “Folder Name 11.39.44”
OK, I’ll have to do some Trash detection and throw up a warning in this case.
Retrobatch stores the locations of the files not as full paths, but rather as what macOS calls “bookmarks” these days (they used to be called “aliases” if anyone remembers those).
The reason why it does this is to play nicely with macOS’s security system, and also for cases where you rename the output folder or move it. Retrobatch will still be able to resolve it in these cases.
RB does store the absolute path as well, in case something happens to the original folder. But just moving a folder to the trash and not emptying it doesn’t delete the folder, so it still resolves as a place for RB to write to.
At any rate, I’ll see what I can do in a future release to make this better.