[njd]

Instead of renaming the file, TagSpaces could create a symbolic link and preserve the original file name. All such links could be managed in a TagSpaces folder.

> ln -s ../fluffy.jpg "fluffy [cat].jpg"

Tags could be added by linking to the latest one:

> ln -s "fluffy [cat].jpg" "fluffy [cat] [yarn].jpg"

This would allow TagSpaces to have temporal knowledge as to when tags were added or removed.

If the links are cascaded as I have shown, then when the original file is moved, TagSpaces will only need to rebuild the first link. The rest will still work.

The issue of the tags causing the name to be too long can be addressed by a different tag naming strategy.

> ln -s ../fluffy.jpg "fluffy [+cat].jpg"

> ln -s "fluffy [+cat].jpg" "fluffy [+yarn].jpg"

> ln -s "fluffy [+yarn].jpg" "fluffy [-yarn].jpg"

This would require TagSpaces to have some simple logic to determine which tags were relevant at a particular point in time.

[cyphar]

That system won't work for very many tags. Unix systems have limits on the number of symbolic links you can resolve when trying to access a file. I can't remember the limit on GNU/Linux off the top of my head but I'm fairly sure its something ridiculous like 32 links.

[njd]

Thanks for pointing that out. Instead of the endless cascade, just cascade once off of the first link. That way, there would never be more than two references to resolve and you still get the temporal benefit.

> ln -s ../fluffy.jpg "fluffy [+cat].jpg"

> ln -s "fluffy [+cat].jpg" "fluffy [+yarn].jpg"

> ln -s "fluffy [+cat].jpg" "fluffy [-yarn].jpg"

[ilian]

This is great idea, but is very Linux/OSX specific, since TagSpaces is multiplatform application, this proposal will not work on Windows or Android platforms.