path: root/write_or_die.c
AgeCommit message (Collapse)Author
2007-07-01Don't fflush(stdout) when it's not helpfulTheodore Ts'o
This patch arose from a discussion started by Jim Meyering's patch whose intention was to provide better diagnostics for failed writes. Linus proposed a better way to do things, which also had the added benefit that adding a fflush() to git-log-* operations and incremental git-blame operations could improve interactive respose time feel, at the cost of making things a bit slower when we aren't piping the output to a downstream program. This patch skips the fflush() calls when stdout is a regular file, or if the environment variable GIT_FLUSH is set to "0". This latter can speed up a command such as: GIT_FLUSH=0 strace -c -f -e write time git-rev-list HEAD | wc -l a tiny amount. Signed-off-by: "Theodore Ts'o" <> Acked-by: Linus Torvalds <> Signed-off-by: Junio C Hamano <>
2007-01-27write_in_full: size_t is unsigned.Junio C Hamano
It received the return value from xwrite() in a size_t variable 'written' and expected comparison with 0 would catch an error from xwrite(). Signed-off-by: Junio C Hamano <>
2007-01-14Remove read_or_die in favor of better error messages.Shawn O. Pearce
Originally I introduced read_or_die for the purpose of reading the pack header and trailer, and I was too lazy to print proper error messages. Linus Torvalds <>: > For a read error, at the very least you have to say WHICH FILE > couldn't be read, because it's usually a matter of some file just > being too short, not some system-wide problem. and of course Linus is right. Make it so. Signed-off-by: Shawn O. Pearce <> Signed-off-by: Junio C Hamano <>
2007-01-12Fix up totally buggered read_or_die()Linus Torvalds
The "read_or_die()" function would silently NOT die for a partial read, and since it was of type "void" it obviously couldn't even return the partial number of bytes read. IOW, it was totally broken. This hopefully fixes it up. Signed-off-by: Linus Torvalds <> Signed-off-by: Junio C Hamano <>
2007-01-12Clean up write_in_full() usersLinus Torvalds
With the new-and-improved write_in_full() semantics, where a partial write simply always returns a real error (and always sets 'errno' when that happens, including for the disk full case), a lot of the callers of write_in_full() were just unnecessarily complex. In particular, there's no reason to ever check for a zero length or return: if the length was zero, we'll return zero, otherwise, if a disk full resulted in the actual write() system call returning zero the write_in_full() logic would have correctly turned that into a negative return value, with 'errno' set to ENOSPC. I really wish every "write_in_full()" user would just check against "<0" now, but this fixes the nasty and stupid ones. Signed-off-by: Linus Torvalds <> Signed-off-by: Junio C Hamano <>
2007-01-11Avoid errors and warnings when attempting to do I/O on zero bytesEric Wong
Unfortunately, while {read,write}_in_full do take into account zero-sized reads/writes; their die and whine variants do not. I have a repository where there are zero-sized files in the history that was triggering these things. Signed-off-by: Eric Wong <> Signed-off-by: Junio C Hamano <>
2007-01-11write_in_full: really write in full or return error on disk full.Linus Torvalds
Signed-off-by: Junio C Hamano <>
2007-01-08short i/o: fix calls to write to use xwrite or write_in_fullAndy Whitcroft
We have a number of badly checked write() calls. Often we are expecting write() to write exactly the size we requested or fail, this fails to handle interrupts or short writes. Switch to using the new write_in_full(). Otherwise we at a minimum need to check for EINTR and EAGAIN, where this is appropriate use xwrite(). Note, the changes to config handling are much larger and handled in the next patch in the sequence. Signed-off-by: Andy Whitcroft <> Signed-off-by: Junio C Hamano <>
2007-01-08short i/o: fix calls to read to use xread or read_in_fullAndy Whitcroft
We have a number of badly checked read() calls. Often we are expecting read() to read exactly the size we requested or fail, this fails to handle interrupts or short reads. Add a read_in_full() providing those semantics. Otherwise we at a minimum need to check for EINTR and EAGAIN, where this is appropriate use xread(). Signed-off-by: Andy Whitcroft <> Signed-off-by: Junio C Hamano <>
2007-01-08short i/o: clean up the naming for the write_{in,or}_xxx familyAndy Whitcroft
We recently introduced a write_in_full() which would either write the specified object or emit an error message and fail. In order to fix the read side we now want to introduce a read_in_full() but without an error emit. This patch cleans up the naming of this family of calls: 1) convert the existing write_or_whine() to write_or_whine_pipe() to better indicate its pipe specific nature, 2) convert the existing write_in_full() calls to write_or_whine() to better indicate its nature, 3) introduce a write_in_full() providing a write or fail semantic, and 4) convert write_or_whine() and write_or_whine_pipe() to use write_in_full(). Signed-off-by: Andy Whitcroft <> Signed-off-by: Junio C Hamano <>
2007-01-07Merge branch 'sp/mmap'Junio C Hamano
* sp/mmap: (27 commits) Spell default packedgitlimit slightly differently Increase packedGit{Limit,WindowSize} on 64 bit systems. Update packedGit config option documentation. mmap: set FD_CLOEXEC for file descriptors we keep open for mmap() pack-objects: fix use of use_pack(). Fix random segfaults in pack-objects. Cleanup read_cache_from error handling. Replace mmap with xmmap, better handling MAP_FAILED. Release pack windows before reporting out of memory. Default core.packdGitWindowSize to 1 MiB if NO_MMAP. Test suite for sliding window mmap implementation. Create pack_report() as a debugging aid. Support unmapping windows on 'temporary' packfiles. Improve error message when packfile mmap fails. Ensure core.packedGitWindowSize cannot be less than 2 pages. Load core configuration in git-verify-pack. Fully activate the sliding window pack access. Unmap individual windows rather than entire files. Document why header parsing won't exceed a window. Loop over pack_windows when inflating/accessing data. ... Conflicts: cache.h pack-check.c
2007-01-03send pack check for failure to send revisions listAndy Whitcroft
When passing the revisions list to pack-objects we do not check for errors nor short writes. Introduce a new write_in_full which will handle short writes and report errors to the caller. Use this to short cut the send on failure, allowing us to wait for and report the child in case the failure is its fault. Signed-off-by: Andy Whitcroft <> Signed-off-by: Junio C Hamano <>
2006-12-29Create read_or_die utility routine.Shawn O. Pearce
Like write_or_die read_or_die reads the entire length requested or it kills the current process with a die call. Signed-off-by: Shawn O. Pearce <> Signed-off-by: Junio C Hamano <>
2006-08-31Trace into open fd and refactor tracing code.Christian Couder
Now if GIT_TRACE is set to an integer value greater than 1 and lower than 10, we interpret this as an open fd value and we trace into it. Note that this behavior is not compatible with the previous one. We also trace whole messages using one write(2) call to make sure messages from processes do net get mixed up in the middle. It's now possible to run the tests like this: GIT_TRACE=9 make test 9>/var/tmp/trace.log Signed-off-by: Christian Couder <> Signed-off-by: Junio C Hamano <>
2006-08-22Add write_or_die(), a helper functionRene Scharfe
The little helper write_or_die() won't come back with bad news about full disks or broken pipes. It either succeeds or terminates the program, making additional error handling unnecessary. This patch adds the new function and uses it to replace two similar ones (the one in tar-tree originally has been copied from cat-file btw.). I chose to add the fd parameter which both lacked to make write_or_die() just as flexible as write() and thus suitable for lib-ification. There is a regression: error messages emitted by this function don't show the program name, while the replaced two functions did. That's acceptable, I think; a lot of other functions do the same. Signed-off-by: Rene Scharfe <> Signed-off-by: Junio C Hamano <>