[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#15015: Fix some minor races in hosts lacking mkostemp
From: |
Eli Zaretskii |
Subject: |
bug#15015: Fix some minor races in hosts lacking mkostemp |
Date: |
Sun, 04 Aug 2013 18:44:24 +0300 |
> Date: Sat, 03 Aug 2013 14:26:20 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: 15015@debbugs.gnu.org
>
> On 08/03/2013 07:55 AM, Eli Zaretskii wrote:
>
> > gettimeofday, open, and lstat are implemented by Emacs in w32.c. At
> > lest the last 2 are not equivalent to what gnulib uses.
>
> The lack of equivalence shouldn't matter. The lstat call
> (though it is compiled) won't be used by Emacs's use of the
> mkostemp module on Microsoft platforms, so it's OK.
> mkostemp always calls 'open' with O_CREAT | O_EXCL; in that
> case sys_open is just a simple wrapper around _open, so that
> should be OK too. And gettimeofday, as you mentioned, isn't
> a problem.
I think sys_open also sets the no-inherit flag, so it's not just a
wrapper.
In any case, even if you are right (and I don't have enough resources
at the moment to verify that), reusing most of the code of sys_mktemp
to implement mkostemp seems like a safer bet, since that code is
already well tested by years of usage. This also has the nice benefit
of not breaking the old configure.bat build.
So I went ahead and implemented mkostemp for MS-Windows (trunk
revision 113687). I also removed sys_mktemp, as it is no longer
needed.
> >> Presumably nt/configure.bat and makefile-w32.in could be updated
> >> to compile the new files. This sort of thing should be routine,
> >> if that avenue is still supported.
> >
> > This "support" needs volunteers, which didn't yet show up.
>
> If nobody's supporting it, then it's not really supported.
That's true, but I'd like to avoid breaking it for as long as is
feasible, to let people adapt.
> > We can always install the gnulib stuff for those other platforms
>
> Yes, that's a given. We need to do that, to fix the race
> condition bugs in OS X, Solaris, etc.
Please go ahead.
> > and work around it on Windows.
>
> I'm trying to help save work in the Windows port, by having
> Windows Emacs use Gnulib mkostemp (which will be in the
> source code anyway) the same way it's being used on OS X etc.
> If this approach is feasible, it should save us all some
> work; if not, it should be easy for a Windows expert to work
> around any problems in w32.c and/or msdos.c.
This approach is generally feasible, and I appreciate your efforts.
It's just that in this case having a Windows-specific implementation
was easy.
(Don't worry about msdos.c, I will fix that when I have time. There
can be no race conditions on MSDOS anyway...)
Thanks.