forum/Slightly finer control over file whereaboutsgit-annexhttp://git-annex.branchable.com/forum/Slightly_finer_control_over_file_whereabouts/git-annexikiwiki2013-11-27T22:47:37Zcomment 1http://git-annex.branchable.com/forum/Slightly_finer_control_over_file_whereabouts/comment_1_6236bcfa9beba705ead3ec2141c5d835/joeyh.name2013-11-27T22:47:37Z2013-09-19T17:57:22Z
That sound like it should work. I suggest you play around with <code>git annex drop --auto</code> at 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.
comment 2http://git-annex.branchable.com/forum/Slightly_finer_control_over_file_whereabouts/comment_2_ea935b37ca93e73c85d04df7c9bf6057/Walter2013-11-27T22:47:37Z2013-09-19T22:22:03Z
<p>So, it sort of works...</p>
<p>I realised that I don't have <code>archive</code> repository but instead <code>backup</code> ones, so adding that makes <code>git annex drop --auto</code> want to drop files in archive/dionysus.</p>
<p>However, the webapp then gets them. This I don't understand.</p>
comment 3http://git-annex.branchable.com/forum/Slightly_finer_control_over_file_whereabouts/comment_3_f89a8e38283ac4c8c4a3b74c413d67a1/joeyh.name2013-11-27T22:47:37Z2013-09-20T00:15:07Z
does <code>git annex get --auto</code> also get them?
comment 4http://git-annex.branchable.com/forum/Slightly_finer_control_over_file_whereabouts/comment_4_07a0a754a089c46ff69dc97ea7ba9384/Walter2013-11-27T22:47:37Z2013-09-20T02:41:22Z
<p>I am testing on my laptop, and the content expression there is
<code>(exclude=archive/kronos/* ) or (not copies=semitrusted+:1)</code>
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.</p>
<p>The problem is that <code>git annex drop --auto</code> does indeed drop things, but <code>git annex get --auto</code> gets them; surely it should not be possible for that to happen?</p>
<p>I also tried the preferred content expression of <code>(exclude=archive/kronos/* )</code>, and the same thing happens.</p>
<p>The version of git-annex that I am using is</p>
<pre>git-annex version: 4.20130919-g9be7762
build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP DNS Feeds Quvi
local repository version: 4
default repository version: 3
supported repository versions: 3 4
upgrade supported from repository versions: 0 1 2</pre>
comment 5http://git-annex.branchable.com/forum/Slightly_finer_control_over_file_whereabouts/comment_5_e884c001a556a0c693d1cc9a97c068ac/joeyh.name2013-11-27T22:47:37Z2013-09-20T15:31:18Z
Ok. This seems to be a bug in git-annex then. While it's surprisingly difficult to do so, it tries to interpet preferred content expressions in a stable way -- that is, they should not want to get a file when it's missing and then want to drop it when it's present.
comment 6http://git-annex.branchable.com/forum/Slightly_finer_control_over_file_whereabouts/comment_6_3e8674b5857e4994dfbc26be4f4b2855/joeyh.name2013-11-27T22:47:37Z2013-09-20T15:36:25Z
<p>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/<em>"
(also tried "(exclude=archive/kronos/</em> ) or (not copies=semitrusted+:1)")</p>
<pre>
joey@darkstar:~/tmp/A>git annex get --auto
joey@darkstar:~/tmp/A>git annex get
get archive/kronos/foo (from origin...) ok
(Recording state in git...)
joey@darkstar:~/tmp/A>git annex drop --auto
drop archive/kronos/foo ok
(Recording state in git...)
joey@darkstar:~/tmp/A>git annex get --auto
joey@darkstar:~/tmp/A>
</pre>
<p>... Which is how you want it to behave.</p>
<p>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.</p>
comment 7http://git-annex.branchable.com/forum/Slightly_finer_control_over_file_whereabouts/comment_7_7aeabc2e52a39423e83fbd04560e8f91/joeyh.name2013-11-27T22:47:37Z2013-09-20T15:37:48Z
Also, please check if you're running into <a href="http://git-annex.branchable.com/bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time/">Handling of files inside and outside archive directory at the same time</a>
comment 8http://git-annex.branchable.com/forum/Slightly_finer_control_over_file_whereabouts/comment_8_53b95449cfad2fe0f72d2ad642822c03/Walter2013-11-27T22:47:37Z2013-09-20T20:30:52Z
<p>Hmm, that could be it; the same content is both inside and outside the archive directory.</p>
<p>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.</p>
<p>But, if that is not going to work, is there a better way to manage that?</p>
<p>By the way, I really appreciate all the work you put into this awesome project.</p>
comment 9http://git-annex.branchable.com/forum/Slightly_finer_control_over_file_whereabouts/comment_9_a17c102a45e4fc3f101a79acb8eb4081/Walter2013-11-27T22:47:37Z2013-09-23T21:58:42Z
<p>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 <em>contents</em> (ie dependent on the hash of the file), but sometimes (preferred content, not sure of anywhere else) caring about file <em>location</em>.</p>
<p>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.</p>
<p>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 <code>dont-want file1 file2 dir1</code> would add these locations to a file, and <code>want file1 file2 dir1</code> would 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.</p>
<p>So, after that ramble, I guess I'm envisaging a preferred content expression like <code>content=(exclude=path/to/file1 and exclude=path/to/file1 and exclude=path/to/dir1/*) or (some statement about numcopies)</code>, which I imagine updating whenever I decide I do/don't want some file. The only obstacle to this working is <a href="http://git-annex.branchable.com/bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time/">Handling of files inside and outside archive directory at the same time</a> (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.</p>
<p>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.</p>
<p>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.</p>
comment 10http://git-annex.branchable.com/forum/Slightly_finer_control_over_file_whereabouts/comment_10_bcb883d46a637dd1a8ef9a92733d202a/joeyh.name2013-11-27T22:47:37Z2013-11-08T18:32:12Z
<p>If I could comprehensively fix that bug I would.</p>
<p>But, it's supposed to already be fixed when using direct mode. Were you using indirect mode when you saw the problem?</p>
comment 11http://git-annex.branchable.com/forum/Slightly_finer_control_over_file_whereabouts/comment_11_b7a8b9eaf114f883866fbf2be51b622f/Walter2013-11-27T22:47:37Z2013-11-09T06:02:36Z
No, this was using direct mode.