[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gzip 1.3.6 (and other recent releases): utime() operation missed or
From: |
Paul Eggert |
Subject: |
Re: gzip 1.3.6 (and other recent releases): utime() operation missed or clobbered at output file close |
Date: |
Fri, 01 Dec 2006 16:39:13 -0800 |
User-agent: |
Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) |
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.