summaryrefslogtreecommitdiff
path: root/tempfile.c
AgeCommit message (Collapse)AuthorFilesLines
2017-02-17tempfile: set errno to a known value before calling ferror()Libravatar Jeff King1-2/+7
In close_tempfile(), we return an error if ferror() indicated a previous failure, or if fclose() failed. In the latter case, errno is set and it is useful for callers to report it. However, if _only_ ferror() triggers, then the value of errno is based on whatever syscall happened to last fail, which may not be related to our filehandle at all. A caller cannot tell the difference between the two cases, and may use "die_errno()" or similar to report a nonsense errno value. One solution would be to actually pass back separate return values for the two cases, so a caller can write a more appropriate message for each case. But that makes the interface clunky. Instead, let's just set errno to the generic EIO in this case. That's not as descriptive as we'd like, but at least it's predictable. So it's better than the status quo in all cases but one: when the last syscall really did involve a failure on our filehandle, we'll be wiping that out. But that's a fragile thing for us to rely on. In any case, we'll let the errno result from fclose() take precedence over our value, as we know that's recent and accurate (and many I/O errors will persist through the fclose anyway). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-16tempfile: avoid "ferror | fclose" trickLibravatar Jeff King1-6/+2
The current code wants to record an error condition from either ferror() or fclose(), but makes sure that we always call both functions. So it can't use logical-OR "||", which would short-circuit when ferror() is true. Instead, it uses bitwise-OR "|" to evaluate both functions and set one or more bits in the "err" flag if they reported a failure. Unlike logical-OR, though, bitwise-OR does not introduce a sequence point, and the order of evaluation for its operands is unspecified. So a compiler would be free to generate code which calls fclose() first, and then ferror() on the now-freed filehandle. There's no indication that this has happened in practice, but let's write it out in a way that follows the standard. Noticed-by: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-23mingw: ensure temporary file handles are not inherited by child processesLibravatar Ben Wijen1-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>
2015-08-10register_tempfile(): new function to handle an existing temporary fileLibravatar Michael Haggerty1-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>
2015-08-10tempfile: add several functions for creating temporary filesLibravatar Michael Haggerty1-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>
2015-08-10prepare_tempfile_object(): new function, extracted from create_tempfile()Libravatar Michael Haggerty1-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>
2015-08-10tempfile: a new module for handling temporary filesLibravatar Michael Haggerty1-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>