[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
Wed, 28 Oct 2009 08:32:49 -0700 (PDT)
> 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?
> -- Reuti
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.
View this message in context:
Sent from the Gnu - Cpio mailing list archive at Nabble.com.