On Tue, Apr 15, 2014 at 02:28:17PM -0400, Nick Mathewson wrote:
On Tue, Apr 15, 2014 at 2:27 PM, Nick Mathewson nickm@alum.mit.edu wrote:
On Mon, Apr 14, 2014 at 5:32 AM, carlo von lynX lynX@time.to.get.psyced.org wrote: [...]
So the question is, would it be okay to catch ESPIPE in all cases, thus having it ignored in tor_fd_seekend, or just catch it in add_file_log? Or is there a reason to impede the use of unix named pipes under all circumstances?
I think it's fine to ignore that failure from tor_fd_seekend in this case. Actually, I'm not clear, looking at the code, why it's there at all: it seems to me that O_APPEND should already put us at the end of the file, right? It's not clear to me why we mask out O_APPEND in start_writing_to_file(). Maybe looking at the git logs will shine some light on it...
Ah. Apparently, O_APPEND has additional semantics beyond when we're opening the file. See commit 37bd9181f07b198ce43489adb5fdb457eef8cfff
Thank you for finding your own commit from many years ago. So apparently O_APPEND ensures that we are always at the end of the file. Is that bad? If so, then let's add that ESPIPE exception and allow for conscious use of pipes.
grarpamp, thanks for your work on more advanced ways to look at the information, but right now it is fine with me to be the first to know that my computer is requesting a circuit to somewhere. Gives me half a second to rip out the cable. ;-)
Here's the patch. This should also work for unices that do not produce ESPIPE and for WIN32 that doesn't have unix-like named pipes. <formal>I place this patch in the public domain.</formal>
--- a/src/common/compat.c +++ b/src/common/compat.c @@ -969,7 +969,12 @@ tor_fd_seekend(int fd) #ifdef _WIN32 return _lseek(fd, 0, SEEK_END) < 0 ? -1 : 0; #else - return lseek(fd, 0, SEEK_END) < 0 ? -1 : 0; + int rc = lseek(fd, 0, SEEK_END) < 0 ? -1 : 0; +#ifdef ESPIPE + /* allow for log output to go to a mkfifo named pipe --symlynX */ + if (rc && errno == ESPIPE) rc = 0; +#endif + return rc; #endif }