[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-cpio] Directory ownership lost in 2.9 and 2.10 when dir not emp
Re: [Bug-cpio] Directory ownership lost in 2.9 and 2.10 when dir not empty
Fri, 30 Oct 2009 08:38:21 -0700
Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:126.96.36.199) Gecko/20090601 SeaMonkey/1.1.16
That delayed strategy is necessary to handle cases where
the parent directory is non-writable.
Try your test again, but change the permissions on the "test"
directory to read-only (chmod 555 test) before creating your
test.cpio archive. I think you'll find that your patch
makes cpio unable to restore the archive.
I expect the real fix is to store ownership, atime,
and mtime in the delay list so that apply_delayed_set_stat()
can apply those as well. (Might rename the routine to
apply_delayed_attributes() while you're making this change.)
this was on the list quite some times as a bug in 2.9. I copy a
directory tree as a result of a "find . -depth" and the ownerships
are not restored when the directoyr is not empty. OTOH, I have to use
-depth to retain the modifications dates of the directory. I hoped
that it would be fixed in 2.10, but it's still there. For now I
continue to use 2.8, which works fine.
I this no longer considered as a bug, and just the correct behavior
in the future?
I have done some work to trace this problem. Here is a way to reproduce
it, an explanation of what is happening, and a workaround patch for 2.10.
Relevant files are attached.
The simple test case directory tree:
Every directory (test, one, two, three) and the file (file) have modified
date of oct 1. I create an archive as follows:
find test -depth | cpio -ov > test.cpio
Then I remove the original tree:
rm -rf test
Now, I restore the tree:
cat test.cpio | cpio -idumv
This results in all nodes except two getting their original oct 1 modify
date. The two exceptions are:
Those two nodes get a modify time set to current system clock. The reason
for this is because they have child nodes and are therefore created by
make_path() which puts them into the delay_set_stat linked list. After all
data is restored, that list is processed by routines that do not have access
to the original directory's ownership and atime and mtime, so that
information gets destroyed and replaced by current system time, etc.
My question is, what is the reason for deferring that operation? Can it be
completed when the directory is created?
The workaround I'm using is to call apply_delayed_set_stat() right after
delay_set_stat(). It is not elegant, but it makes the directory stats and
timestamps come out correctly. I do not really know if that adversely
affects some other operational case, which is why I'd like this reviewed by
someone more familiar with that code's intent.