[Top][All Lists]

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

Re: mktemp's access mode and inotify

From: Eric Blake
Subject: Re: mktemp's access mode and inotify
Date: Thu, 12 May 2011 12:43:35 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.10

On 05/12/2011 12:05 PM, David Thomas wrote:
> So I've come across something I think is interesting, and may turn
> into an associated bug report / feature request / patch, but I am
> wondering first just generally what people's thoughts are.

Thanks for the report.

> It specifically has to do with how mktemp plays with inotify.  Since
> mkstemp opens the file with the write bit set (or, well, technically
> unset - but "able to read") when the file is closed inotify receives a
> IN_CLOSE_WRITE event on the directory.

mktemp doesn't play with inotify any differently than any other app that
calls open(,O_CREAT|O_EXCL|O_RDWR).

> to play well, ensuring that a process listening for IN_CLOSE_WRITE
> only sees a file once it is complete (absent error, which must be
> handled correctly - but we're avoiding any chance of catching the file
> incomplete-but-still-to-be-completed, as well as a spurious wakeup of
> the listening process).

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?  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).

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?

Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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