Branko Čibej wrote:
> Greg Hudson wrote:
>
>> BDB code review? I'm not sure how that could be relevant.
>
> The problem shows up when a write to stdout finds its way into a file
> opened by BDB, doesn't it? If BDB opens files differently on Windows
> than it does on Unix, we're safe.
I just happens to be BDB in a lot of cases, but it could be any file. It
depends on the order in which files are opened. If you're using fsfs,
you'll probably corrupt an fsfs file. If you're using a remote command,
you'll probably write garbage (i.e. intended stdout/stderr output) to
the socket, etc.
> Handles aren't really the issue here, because there are no
> "well-known" handle values for the standard streams. But the CRT does
> provide a file-descriptor-like interface where FD's 0, 1, and 2 _are_
> special, and the standard C FILE* streams stdin, stdout and stderr are
> bound to those. Those streams can be closed just like on Unix, and
> from all I've seen, stream slots are assigned sequentially. So we
> could potentially be exposed to the same problem on Windows.
Max's experiments indicates that a new process will always have fds
0/1/2 open, which means that we don't have this problem on Win32. On the
other hand, it's better to be safe than sorry, so if someone with a
Win32 build environment would like to adapt the fix to WIN32, it's
probably a good idea, but unless we can have such a fix really soon, I
don't think we should delay the fix for unix. There's nothing preventing
a Win32 fix from going in later.
/Tobias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 6 09:18:04 2004