I have my music library in music/ and some really old files I recently added in reallyold/. There are some MP3s in the really old files and some are the same as my library, so of course git annex is only keeping one copy. Now, I have an rsync remote, ma, which prefers content from music/ but doesn't want anything from reallyold/. So while right now it is trying to drop stuff, I suspect at some point that it will try to re-add them in virtue of being in music/, as I've got a loop.
I want to eliminate this by using the present keyword to disable dropping for stuff in reallyold/ and music/. Here is my attempt, which doesn't work--I am hoping someone can spot what's wrong.
(present and include=music/*) or (present and include=reallyold/*) or (exclude=reallyold/* and exclude=video/* and exclude= ...)
Note that music is included by virtue of not being excluded so it should satisfy the third disjunct. Thanks.
I find it's useful, when stuck on this kind of thing, to run
git annex findat the command line passing it parts of the expression and making sure it works, and gradually building up to the complete expression.You have to do some conversion due to differences between command line and preferred content expression format. For example
git annex find -\( --in here --and --include "music/*" -\)I have now investigated this further and believe that what I am trying to do is impossible. Suppose we have a file
song.mp3in bothmusic/andold/and the special remote's preferred content expression is set-up to prefermusic/and not to preferold/. So initially, git-annex won't try to upload the content when it scansold/song.mp3, but it will when it scansmusic/song.mp3. Fine. Now consider a later scan. On scanning the filenamemusic/song.mp3git-annex will suppose the file was dropped from the remote, and then see it would be preferred again so won't drop it. But then when it gets to scanning the filenameold/song.mp3it will see that it wouldn't be preferred and will drop the content. So we get the loop.In order to stop the unwanted drop here, the preferred content expression must prefer "files in old/ that is also in music/" but since preferred content expressions concern filenames without reference to their contents, this is impossible to express. The expression
include=music/* and include=old/*will never match anything.spwhitton, your analysis is correct -- except this problem was finessed in git-annex version 4.20130621. Now, when using direct mode, it knows that
old/song.mp3is alsomusic/song.mp3, and so it only drops it if the preferred content expression allows dropping both files.Still doesn't work in indirect mode, and I think not likely to in the forseeable future. See Handling of files inside and outside archive directory at the same time
I assume you mean that if I use direct mode locally, it will get things right. I didn't think a special remote could ever be in direct mode.
Thank you for the info. I don't want to lose the safeguards of indirect mode just for this, so I'll stick with my inelegant manual preferred content strings for now.