bugs/Handling of files inside and outside archive directory at the same timegit-annexhttp://git-annex.branchable.com/bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time/git-annexikiwiki2013-11-27T22:47:37Zcomment 1http://git-annex.branchable.com/bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time/comment_1_e8bb3d6a2318402b985caed08282d473/joey2013-11-27T22:47:37Z2013-04-11T16:32:43Z
<p>This is a known problem.</p>
<p>It seems possible to fix it for direct mode. After all, direct mode tracks all files associated with a key, so it could expose this to preferred content expressions, and the expression check if any of the associated files was in an archive directory.</p>
<p>Unsure how to deal with it in indirect mode. Short of making indirect mode do all the same tracking direct mode does, or otherwise build a key to file lookup table.</p>
comment 2http://git-annex.branchable.com/bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time/comment_2_ead9fa75a12ef36be9a92637b144e74f/joey2013-11-27T22:47:37Z2013-06-15T17:52:36Z
<p>This turns out to be much worse in direct mode than in indirect mode.</p>
<p>In indirect mode, it only does extra work during the full startup scan. Suppose there are 3 files with the same content, 1, archive/2, and 3. It will download 1, and then will drop archive/2, and then will download 3. This certainly is not ideal, especially when the file content is large.</p>
<p>In indirect mode, it continally and repeatedly downloads the drops the files, as long as it's running. Which is beyond unacceptable.</p>
<p>What seems to be going on is that when archive/2 gets dropped, it necessary needs to convert 1 and 3 to broken symlinks. But the watcher than sees those file changes, thinks these are new or renamed files that have appeared, and promptly re-downloads them. That, in turn triggers an update of archive/2, to convert it back from symlink to direct mode file, and that in turn is noticed by the watcher. Round and round we go!</p>