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:
Joey Hess 2019-09-30 17:12:47 -04:00
parent 3b8c94fcbd
commit 3066bdb1fb
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
4 changed files with 28 additions and 15 deletions

View file

@ -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]]