Re: gzip 1.3.6 (and other recent releases): utime() operation missed or clobbered at output file close

[Paul Eggert]

Ronan MELENNEC <address@hidden> writes:

> The current order of operations in gzip 1.3.6
> at the moment of closing the output file is
> the following :
>
>  utime() on pathname attached to output file
>  fchmod(), fchown() on open output descriptor
>  close()  on open output descriptor

That's not what I observe on my host (Debian stable, running Linux
2.4.27-3-686).  If I run these command:

   echo abc >foo
   strace -o tr gzip foo

then 'tr' ends this way:

   read(3, "abc\n", 65536)                 = 4
   read(3, "", 65532)                      = 0
   write(4, "\37\213\10\10\371\304pE\0\3foo\0KLJ\346\2\0N\201\210G\4"..., 28) = 
28
   close(3)                                = 0
   utimes("/proc/self/fd/4", {1165018337, 0}) = -1 ENOSYS (Function not 
implemented)
   utime("/proc/self/fd/4", [2006/12/01-16:12:17, 2006/12/01-16:12:41]) = 0
   fchmod(4, 0644)                         = 0
   fchown32(4, 1000, 1000)                 = 0
   close(4)                                = 0
   unlink("foo")                           = 0
   exit_group(0)                           = ?

So 'utime' is not being applied to a pathname attached to the output
file; it's being applied to the fd itself, via the /proc file system.

If things work differently on your host, can you please send us
a similar strace output?

Also, can you please check whether your kernel is suffering from the
fchmod bug that 2.6.16.9 has in this area?  That could explain the
problem.  Please see <http://bugs.gentoo.org/show_bug.cgi?id=132673>.

Thanks.


> There is, in both cases, unavoidable race conditions
> related to potential third-party file name changes while the output
> file is being filled ; the change of ordering outlined above doesn't
> substantially worsen the situation.

On my host, anyway, 'utime' is applied to /proc/self/fd/4, not to
/tmp/foo, so it's unaffected by race conditions like some other
process replacying /tmp/foo with a symlink.

Most likely there's some portability problem on your host, but we'll
need more info (e.g., an strace output) to see what it is.

PS.  please send patches in "diff -u" format rather than sending is
the entire new file; that makes them easier to analyze.  Thanks.