fix longstanding indeterminite preferred content for duplicated file problem
* drop: When two files have the same content, and a preferred content expression matches one but not the other, do not drop the file. * sync --content, assistant: Fix an edge case where a file that is not preferred content did not get dropped. The sync --content edge case is that handleDropsFrom loaded associated files and used them without verifying that the information from the database was not stale. It seemed best to avoid changing --want-drop's behavior, this way when debugging a preferred content expression with it, the files matched will still reflect the expression. So added a note to the --want-drop documentation, to make clear it may not behave identically to git-annex drop --auto. While it would be possible to introspect the preferred content expression to see if it matches on filenames, and only look up the associated files when it does, it's generally fairly rare for 2 files to have the same content, and the database lookup is already avoided when there's only 1 file, so I did not implement that further optimisation. Note that there are still some situations where the associated files database does not get locked files recorded in it, which will prevent this fix from working. Sponsored-by: Dartmouth College's Datalad project
This commit is contained in:
parent
78be7cf73f
commit
a56b151f90
7 changed files with 62 additions and 20 deletions
|
@ -19,3 +19,5 @@ So, this seems solvable in v7 repositories, but not in v5.
|
|||
Also, the associated files map may not be accurate at all times, so that's
|
||||
a wrinkle to using it for this. Also, only unlocked files get into the
|
||||
associated files map. --[[Joey]]
|
||||
|
||||
> [[fixed|done]] --[[Joey]]
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue