fix annex.largefiles largerthan/smallerthan bug
Fix bug in handling of annex.largefiles that use largerthan/smallerthan. When adding a modified file, it incorrectly used the file size of the old version of the file, not the current size. That was the only largefiles limit that didn't directly look at the file on disk already. Added a new type to keep straight the two different ways such a limit can be matched. I kind of wanted to extend MatchingFile or FileInfo to indicate that the matcher is supposed to operate on files from disk or annex, but it turned out to be too complex to implement it that way. This also changes the LimitAnnexFiles case when lookupFileKey does not find a key. It used to fall back to statting the file, now it always returns False. I doubt the old code could really get to that point, but if it somehow does, it's better for preferred content matching to be consistent.
This commit is contained in:
parent
3b8c94fcbd
commit
3066bdb1fb
4 changed files with 28 additions and 15 deletions
|
@ -39,3 +39,5 @@ or by --largerthan.
|
|||
|
||||
But, for matching largefiles, it needs to look at the actual file on disk,
|
||||
not an old key.
|
||||
|
||||
> [[fixed|done]] --[[Joey]]
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue