-
Notifications
You must be signed in to change notification settings - Fork 114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
symlinkTargetNameNoExt: Fall back on regular hashing for regular files. #40
Comments
The Yes it would be possible to fall back to regular hashing in the case of regular files but as you have expressed this would be somewhat hard to configure with the current set-up. One solution is the comma-seperated list of preferences as you proposed; another would be to split out the configuration of the hash algorithm for each type of file. Already TMSU allows files and directories to be configured separately so perhaps this could be extended to allow symbolic links to be separately configured? |
This would be a lot more complex to implement and configure but I will have a think about how it could work. |
Added 'symlinkFingerprintAlgorithm' setting with possible values of 'none', 'follow', 'targetName' and 'targetNameNoExt'. Added schema upgrade logic for converting existing settings.
So what I've done is to:
|
This makes the symlink handling more consistent! Thanks! 👍 |
I was trying to set up TMSU for use within a git-annex repository, and was delighted to see the
symlinkTargetName{,NoExt}
option exist. However, it seems that when a regular (non-symlinked) file is tagged, tmsu will still use the name as the fingerprint (despite what the option name indicates). Would it be reasonable to fall back to a regular hash for non-symlinked files? Perhaps by specifying the desired digest in a setting, such assymlinkTargetNameNoExt,dynamic:SHA1
?In the best case, tmsu could also fall-back to its regular behavior when the file is a symlink, but the target name is not “special”. If the config option is meant to target git-annex interoperability, git-annexes known key formats could be used as a pattern against which to match; alternatively, it could be checked whether the symlink goes to
[…]/.git/annex
. Or, for a more generic solution, maybe a config option specifying a regular expression might be viable?Thanks for making TMSU!
The text was updated successfully, but these errors were encountered: