2a41712ef1
This is only done for correctness sake; I don't see any way that it would have caused a problem here. The jlog file escaped withOtherTmp so another process could swoop in and delete it, but the file is only used as a buffer for a list of filenames, and its handle gets rewound and they're read back out, which will still work even if it's already been deleted. The only reason I didn't just pre-delete the file and keep the handle open is I'm not sure that works on all OS's (eg Windows). If there was a problem that this fixed it might involve an OS that doesn't support deleting an open file or something like that.
22 lines
1,018 B
Markdown
22 lines
1,018 B
Markdown
This was reported with concurrent processes, I think probably during a `git
|
|
annex add` but not sure:
|
|
|
|
git-annex: .git/annex/othertmp/inge59014-3: getFileStatus: does not exist (No such file or directory)
|
|
failed
|
|
|
|
git-annex: .git/annex/othertmp/ingest-assemble_den59014-8: removeLink: does not exist (No such file or directory)
|
|
failed
|
|
|
|
From the "ingest" in the name, these files are from
|
|
`Annex.Ingest.lockDown'`, which uses `withOtherTmp`, hard links the file
|
|
into the temp directory, and then returns a LockedDown that includes the
|
|
temp filepath. So, it's escaped the locking that `withOtherTmp` does, and
|
|
another process can clean up the temp files at the wrong point in time.
|
|
This will need some significant code reworking to fix.
|
|
|
|
This is a fairly new problem because the code to have other processes
|
|
cleanup stale othertmp files was only added a couple months back.
|
|
|
|
I audited other uses of withOtherTmp, and the only other problem I found is
|
|
similar, in Annex.Branch.stageJournal. Fixed that one.
|
|
--[[Joey]]
|