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

[Ronan MELENNEC]

Hello,

This report is not in any canonical format, please
excuse me for this.


When closing gzip output file, its timestamps
are (by default) put in sync with those of the original file.

On a Linux 2.6.x this is typically done through
a call to utime().

There is a condition (e.g. when output file is NFS-mounted)
where utime() results are clobbered by the subsequent close()
operation (I don't know enough about NFS to be more specific).
The end result is that the -N option is ignored (or the -n option
is forced with respect to file times).

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

Changing the order of operations to :

 fchmod(), fchown() on open output descriptor
 close()  on open output descriptor
 utime() on output pathname

solves the problem.

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. Possibly reopening the
output file descriptor (using open("/dev/fd/xxx", O_RDONLY)) and
applying fchmod(),fchown() on the reopened fd) might solve this race
condition. I haven't tried this, nor checked the portability issues.

Please find attached a changed gzip.c.
I've split the copy_stat() function in two,
yielding copy_mode() and copy_time( (the latter being now called
after file close).

Cordially,
--
Ronan Melennec          | DGAC/DSNA/DTI/SDER/3/RFM
<address@hidden>  | Division Routes, Flux et Modélisations (RFM)
+33 (0) 1 69 57 69 28   | Orly Sud 205 -- 94542 ORLY AEROGARE CEDEX
FRANCE
--

gzip.c
Description: gzip.c