I have previously been confused by how to have a bit more manual control over where files are (as in ?git-annex immediately re-gets dropped files).
I thought perhaps something like an archive directory would work, but as I might want different computers to have different content, perhaps a per-computer archive repository.
To that end, I have
walter@dionysus:~/annex$ git annex content . (exclude=archive/dionysus/* or (not (copies=archive:1 or copies=smallarchive:1))) or (not copies=semitrusted+:1) ok
which is a modified version of the archive preferred content, but with the intention that I change the part after exclude to be different for each client.
I also set the group to client for this client (dionysus).
However, it does not seem to drop files when I move them into archive/dionysus/, and I cannot see anything in the logs to suggest why.
What am I doing wrong here? Or, is this the wrong approach?
--Walter
git annex drop --autoat the command line. It will probably tell you why it is unable to drop a file if the problem is something like not enough copies located elsewhere. Or, if it doesn't try to drop the file at all, you'll know your preferred content expression makes it want to keep the file.So, it sort of works...
I realised that I don't have
archiverepository but insteadbackupones, so adding that makesgit annex drop --autowant to drop files in archive/dionysus.However, the webapp then gets them. This I don't understand.
git annex get --autoalso get them?I am testing on my laptop, and the content expression there is
(exclude=archive/kronos/* ) or (not copies=semitrusted+:1)to simplify things; I interpret this to mean it wants everything not in archive/kronos, and it wants things there where that's the only copy.The problem is that
git annex drop --autodoes indeed drop things, butgit annex get --autogets them; surely it should not be possible for that to happen?I also tried the preferred content expression of
(exclude=archive/kronos/* ), and the same thing happens.The version of git-annex that I am using is
I tried to reproduce this behavior, but failed. My configuration was 2 repos, A and B, with B the origin of A. A was configured with "exclude=archive/kronos/" (also tried "(exclude=archive/kronos/ ) or (not copies=semitrusted+:1)")
... Which is how you want it to behave.
So I wonder if it's something else in your configuration. The best thing to do would be if you can come up with a series of commands I can follow to build repositories that exhibit the problem.
Hmm, that could be it; the same content is both inside and outside the archive directory.
What I really want to do (because maybe I'm not going about this the best way) is to use the assistant not in manual mode, but allow for some repos not having some files. I thought by placing them in an archive directory, then they would be dropped, and to get them again, I can just delete from the archive dir, and they will be got (as the file is also outside the archive dir.
But, if that is not going to work, is there a better way to manage that?
By the way, I really appreciate all the work you put into this awesome project.
Thinking about this further, I'm not entirely sure what I want. I think the confusion arises from git-annex sometimes (mostly) caring about file contents (ie dependent on the hash of the file), but sometimes (preferred content, not sure of anywhere else) caring about file location.
What I think I actually want is a way of specifying locations that are not synced, such that if the file is changed somewhere (on another computer), the new version should not be downloaded. But, if the same content is in another location as well, the behaviour should be stable, I don't know how that should work though.
So, perhaps the best strategy is to have an explicit list of locations that I don't want, in the preferred content expression, if it could cope with files being in and out of some location at the same time. I think this would be easiest if I could avoid manually editing the expression all the time, maybe make a file with a list of file locations, if it would be possible for git-annex to handle that? I think it isn't at the moment, and my haskell is non-existent. That way, I could write some helper to add and remove files from this list. For example
dont-want file1 file2 dir1would add these locations to a file, andwant file1 file2 dir1would remove them from this list. Actually, I suppose I could make it just create an appropriate preferred-content expression, and then it doesn't need to support some file of locations.So, after that ramble, I guess I'm envisaging a preferred content expression like
content=(exclude=path/to/file1 and exclude=path/to/file1 and exclude=path/to/dir1/*) or (some statement about numcopies), which I imagine updating whenever I decide I do/don't want some file. The only obstacle to this working is Handling of files inside and outside archive directory at the same time (as I understand that bug, could be wrong on the implications of it), meaning (of course) if there are two files with the same content, and I exclude one of them, and not the other, then it both wants and doesn't want the file, and it (and I) get really confused.I suppose a short-term (well, slow) solution is to find duplicates of files I don't want, and if that exists either add the duplicate to my content expression (to say I don't want it), or remove the one I don't want from the expression (to say I do). This doesn't work well for when the content of one of the files changes (and so they are no longer duplicates), but I think I would search for them each time I generate the expression, so at that time it would no longer find the duplicate.
So, @joey, I guess my question is, what are the chances of that bug being resolved somehow? Or if that is not likely to happen soon, I might try to implement my solution outline from the previous two paragraphs.
If I could comprehensively fix that bug I would.
But, it's supposed to already be fixed when using direct mode. Were you using indirect mode when you saw the problem?