summaryrefslogtreecommitdiff
path: root/tempfile.c
Commit message (Collapse)AuthorAgeFilesLines
* mingw: ensure temporary file handles are not inherited by child processesbw/mingw-avoid-inheriting-fd-to-lockfileBen Wijen2016-08-231-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the index is locked and child processes inherit the handle to said lock and the parent process wants to remove the lock before the child process exits, on Windows there is a problem: it won't work because files cannot be deleted if a process holds a handle on them. The symptom: Rename from 'xxx/.git/index.lock' to 'xxx/.git/index' failed. Should I try again? (y/n) Spawning child processes with bInheritHandles==FALSE would not work because no file handles would be inherited, not even the hStdXxx handles in STARTUPINFO (stdin/stdout/stderr). Opening every file with O_NOINHERIT does not work, either, as e.g. git-upload-pack expects inherited file handles. This leaves us with the only way out: creating temp files with the O_NOINHERIT flag. This flag is Windows-specific, however. For our purposes, it is equivalent to O_CLOEXEC (which does not exist on Windows), so let's just open temporary files with the O_CLOEXEC flag and map that flag to O_NOINHERIT on Windows. As Eric Wong pointed out, we need to be careful to handle the case where the Linux headers used to compile Git support O_CLOEXEC but the Linux kernel used to run Git does not: it returns an EINVAL. This fixes the test that we just introduced to demonstrate the problem. Signed-off-by: Ben Wijen <ben@wijen.net> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* register_tempfile(): new function to handle an existing temporary fileMichael Haggerty2015-08-101-0/+8
| | | | | | | | | | | | | Allow an existing file to be registered with the tempfile-handling infrastructure; in particular, arrange for it to be deleted on program exit. This can be used if the temporary file has to be created in a more complicated way than just open(). For example: * If the file itself needs to be created via the lockfile API * If it is not a regular file (e.g., a socket) Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* tempfile: add several functions for creating temporary filesMichael Haggerty2015-08-101-0/+53
| | | | | | | | | | | | | Add several functions for creating temporary files with automatically-generated names, analogous to mkstemps(), but also arranging for the files to be deleted on program exit. The functions are named according to a pattern depending how they operate. They will be used to replace many places in the code where temporary files are created and cleaned up ad-hoc. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* prepare_tempfile_object(): new function, extracted from create_tempfile()Michael Haggerty2015-08-101-7/+13
| | | | | | | | | | | | This makes the next step easier. The old code used to use "path" to set the initial length of tempfile->filename. This was not helpful because path was usually relative whereas the value stored to filename will be absolute. So just initialize the length to 0. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* tempfile: a new module for handling temporary filesMichael Haggerty2015-08-101-0/+238
A lot of work went into defining the state diagram for lockfiles and ensuring correct, race-resistant cleanup in all circumstances. Most of that infrastructure can be applied directly to *any* temporary file. So extract a new "tempfile" module from the "lockfile" module. Reimplement lockfile on top of tempfile. Subsequent commits will add more users of the new module. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>