git-annex/doc/bugs/git_annex_fsck_--time-limit_broken.mdwn

### Please describe the problem.
`git annex fsck --time-limit=` is broken. <br>
For one, there is a large delay between the specified time limit until something actually happens. With 20 seconds, `git annex fsck` always runs more than 5 minutes. And then something of the following happens: <br>
Sometimes it works as intended. <br>
Sometimes it prints "Time limit (20s) reached!" but hangs without exiting. <br>
Sometimes it prints "Time limit (20s) reached!" but continues fscking. <br>

### What steps will reproduce the problem?
In a sufficiently large repo run `git annex fsck --time-limit=20s`.

### What version of git-annex are you using? On what operating system?
8.20201127

> [[fixed|done]] --[[Joey]]
2021-01-01 15:43:43 +00:00			`### Please describe the problem.`
			`git annex fsck --time-limit=` is broken. <br>
			For one, there is a large delay between the specified time limit until something actually happens. With 20 seconds, `git annex fsck` always runs more than 5 minutes. And then something of the following happens: <br>
			`Sometimes it works as intended. <br>`
			`Sometimes it prints "Time limit (20s) reached!" but hangs without exiting. <br>`
			`Sometimes it prints "Time limit (20s) reached!" but continues fscking. <br>`

			`### What steps will reproduce the problem?`
			In a sufficiently large repo run `git annex fsck --time-limit=20s`.

			`### What version of git-annex are you using? On what operating system?`
			`8.20201127`

fix --time-limit It got broken in several ways by the streaming seeking optimisations around version 8.20201007. Moved time limit checking out of the matcher, which was a hack in the first place. So everywhere that uses Limit.getMatcher needs to check time limit. Well, almost everywhere. Command.Info uses it, but it does not make sense to time limit getting info. And Command.MultiCast uses it just to build up a list of files that then get passed to a command, so it would never have hit the timeout in a useful way. This implementation is a little more expensive when at time limit than necessary, since it continues seeking only to discard everything after the time limit. I did try making it close the file handles to force a faster shutdown, but that didn't work and hung. Could certianly be improved somehow, but seeking is probably not the expensive bit when a time limit is hit, so this seems acceptable for now. 2021-01-04 19:25:28 +00:00			`> [[fixed\|done]] --[[Joey]]`