Re:Show HN: TagSpaces – An open source personal data manager
by cyphar on Tuesday October 11, 2016 @12:07PM
(#12685690)
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.
Re:Show HN: TagSpaces – An open source personal data manager
by njd on Tuesday October 11, 2016 @06:09PM
(#12688932)
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"
> 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.