Hi Stefan, Stefan Beller wrote: > On 22.12.2014 13:22, Junio C Hamano wrote: >> Loic Dachary <l...@dachary.org> writes:
>>> fatal: Unable to create >>> /home/gitmirror/repositories/Ceph/ceph/refs/heads/pull/1917.lock': Too many >>> open files [...] >> Stefan, want to take a look? I think we do need to keep the .lock >> files without renaming while in transaction, but we do not have to >> keep them open, so I suspect that a fix may be to split the commit >> function into two (one to close but not rename, the other to >> finalize by renaming) or something. Makes sense. > Sounds reasonable. Though by closing the file we're giving up again a > bit of safety. If we close the file everyone could tamper with the lock > file. (Sure they are not supposed to touch it, but they could) At least on Linux, keeping a file open doesn't offer any protection against someone else deleting it. (It also doesn't offer any protection against someone updating the ref directly. ;-) Opening the corresponding .lock file with O_EXCL is part of the contract for updating refs.) Thanks, Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
