coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mktemp's access mode and inotify


From: David Thomas
Subject: Re: mktemp's access mode and inotify
Date: Thu, 12 May 2011 11:54:19 -0700

On Thu, May 12, 2011 at 11:43 AM, Eric Blake <address@hidden> wrote:

> Oh, so you're basically asking whether instead of using mkstemp(3)'s
> POSIX-mandated O_RDWR, mktemp(1) should use O_RDONLY when creating the
> temporary file?

Right, exactly.


> The problem is that even though mktemp(1) uses a modified version of glibc's
> __gen_tempname under the hood for creating the file (as exposed by gnulib
> and slightly modified by coreutils), the glibc interface explicitly masks off
> O_ACCMODE and replaces it with O_RDWR, so there is no library interface
> for requesting an O_RDONLY creation of a temporary file that will just then be
> closed.
>
> Maybe it makes to make yet another tweak to coreutils/gl/lib/tempname.c.diff 
> to
> let coreutils also specify the preferred access mode to use then generating a
> temp name where it will just be closed afterwards, for use in mktemp(1).

Yeah, I came in hoping it would be trivial and instead it should just
be easy... a
shame, but I'll take a swing at it.


> Inotify is not part of POSIX, so there is no way a POSIX compliant
> application can tell whether mktemp(1) used O_RDONLY or O_RDWR, so I
> don't see how this can affect anything other than fewer unwanted inotify
> events; I guess it seems safe enough.  Would you like to contribute a patch?

A very good point.  I guess my only concern would be whether a POSIX
compliant libary/OS could require write access to create a file - skimming the
spec, it didn't immediately jump out one way or the other.  Assuming I
don't hear
any objections beforehand, I'll get a patch rolled up in the next few
days (sometime
after my home internet is hooked up...).

Thanks :)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]