Enrico Zini wrote: > This way the git repo is unaffected, and git-annex still has a way to > see that the file is not really available here, because it can detect > that what's in the annex really is just a symlink pointing to the > degraded area.
I know a few people have mentioned wanting something like this. Nice idea of Elena to handle it this way. I think she's just about right in her design. Questions I need to think through: 1. Should a symlink to the degraded file be used? It's unbeleivable how many people are somehow stuck using filesystems without symlinks, but there they are. Seems like a hard link would work as well. Except oops, half the world still doesn't have hardlinks yet either. 2. In either case, it needs to do an extra readlink or stat of either the symlink or the hardlink, or some kind of other flag file, where it currently just stats the object to see if it's present in the local annex. So a little extra work, which seems it's going to have the same cost no matter what is decided WRT #1. 3. How does the user provide degraded files to the annex? I suppose it could be something like: imagemagick file.jpg | git-annx degraded file.jpg And git-annex then can look at file.jpg to get the key, and slurp up the degraded content provided for it. 4. Should degraded content be stored as regular git-annex objects? I can see plusses (ability to copy them around, back them up etc) and minuses (makes it harder for git-annex to keep track of what's a degraded file and what's not; it would need a mapping if the degraded files are not stored in a special location). So far the minuses seem to outweigh the plusses. 5. Is a 1:1 mapping between objects and degraded files sufficient? It's simple, but then maybe someone wants a common degraded file for *.png or even just for * (could be useful on those systems without symlinks, where the current "placeholder" is a regular file containing the symlink target). -- see shy jo
signature.asc
Description: Digital signature
