[FR] Batch rename, Append Tags

[cptvincer]

I was really surprised to see the export of tags into metadata already in- so few apps bother with it and its already covered, amazing!

Sadly few apps can read or work well with proper tags in metadata, and because of that (and to make things future proof) ive got used to writing tags in filenames, and it pays off- when i add a folder where i have gone through the slog of writing tags in filenames they already work in Allusions quick search amazingly well :)

So ive wondered, would it be possible to rename/append Allusion`s tags to filenames?
Im enjoying the app so much and tagging is so nice i would rather do that tag-filename in allusion...

Tag in filenames would also work around the location-removal=tag loss in Allusion.

I tried stress testing allusion (adding a folder with lots of subfolders/files) and realized theres a limit in performance (at least on the startup, my test crashed allusion when starting/checking for new files). I dont know if thats only an issue with checking on startup but i assume theres probably some limit to how many folders/files it can handle, ram resources and so on- no matter the limit we could just add/remove folders on the fly (i really dig the remove/re-add option for subfolders)... but that would mean loosing any applied tags as they are now.
With rename/append tags to filenames one could simply append tags before removing a folder, and quickly re-applying tags via search/select-all when re-adding locations.

[RvanderLaan]

Mhh, I understand where you're coming from, but it'd add quite some complexity:

• file paths can only be a certain length, so there would be a limit on the amount of tags you could apply
• when saving tags to filenames for a second time, it'd be unclear which characters in the filename were tags that were appended before, or just part of the filename
• when removing/renaming a tag, all related files would need to be renamed too. For files synced over Dropbox, they'll all have to be re-uploaded too (just like when saving tags in the metadata)
• file paths are used as a unique identifier for quite some features in Allusion, those would need to be rewritten to support this

And practically speaking, any other programs where those files were in use would become unlinked (in Photoshop or wherever)

So, I don'think this is going to be achievable in the foreseeable future

[cptvincer]

Im sad to read that, in particular the last bullet point.

Regarding the other points:

• i was thinking something more like the export metadata- not something done in realtime as tags are applied/removed/renamed in Allusion but an active function like right-clicking on a file selection and choosing 'rename'
• what about replace/rename instead of append? Jumping the trouble of even trying to figure out anything about the current filename, just a command to 'rename as ' (that would add numbers on the end if names repeat, or possibly other choices of suffix/prefix like date)
• maybe a character/tag limit on the function to avoid long file names?

Just trying to figure out how it could be done. Writing keywords in filenames has been a lifesaver for me for ages now (i have files dating back to the early-mid 2000s that could find and filter across apps thanks to 'tagging' in filenames), its future proof and understandable by pretty much every app. Thats how i could tag a bunch of files quickly in Allusion, since i have a number of files with keywords in filenames i just did a few queries for filename and made Allusion tags to match.

I kinda did rename as tags from Allusion in a clunky way, externally- i was playing around with export tags to metadata, re-checking wich apps i use that could see iptc tags when i remenbered XNview could find by iptc keywords and have a robust batch rename- so i filtered some files by the iptc tags i applied in Allusion and could batch rename all the files including all iptc tags used by each.
And theyre appearing in Allusion fine. 5-6 tags in filename.

The tricky bit that made me sad was the point about filepath lenght in Allusion. Limiting or warning users of long renames (too many tags) would probably be trivial, but in no way im asking for a full rewrite of the logic behind the app just for this, that would be a whole other ball.

But that aspect is something that can be left to user and should- its how the program works, its limitations. Its already that way, for example im sure ive hit some wall in regards to long filepaths in one of my tests (i imported a folder with too many subfolders upon subfolders and Allusion crashed).
That sort of thing will likely never change, its just a reality users have to keep in mind. I had to cleanup thumbnails cache constantly when i used adobe bridge(or it would slow to a crawl), i shouldnt dare to add more then a certain amount of files to eagle...

I think that part can be 'solved' by just making clear in documentation users should avoid long filepaths/filenames, leaving to the user to adjust or change things if they dont heed the warning.
For example now that i know filepath length is such a factor i will try changing wich folders and how i will import in Allusion, both to acommodate longer filenames but also to avoid the crashs and issues i had prior

But no worry, it was a low priority feature idea anyway. I would love to see it someday sure but its in no way essential. Im loving what you guys are doing, im just too excited and throwing ideas around :)

[hummingly]

file paths can only be a certain length, so there would be a limit on the amount of tags you could apply

I assume @RvanderLaan is talking about operating system related limitations like there are on windows. Allusion itself should be able to store paths of any length as long as there is enough space on the device, though we have not written tests for that specially. Bug reports are welcome but I think the crash comes from not limiting RAM usage on scanning the directories.

As for the loss of locations, the tag data itself is retained in the database. You can try it out by (re)moving the folder of a location. The location related files will be marked as deleted but the data itself stays until you delete them yourself, which means backups will still contain the data. You can recover the location (context menu entry or broken icon button next to location) and it should look as before.