[Top][All Lists]

[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

From: Tim Kientzle
Subject: Re: [Bug-cpio] Directory ownership lost in 2.9 and 2.10 when dir not empty
Date: Fri, 30 Oct 2009 08:38:21 -0700
User-agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv: 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.)



asc1000 wrote:

Reuti wrote:

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.

http://www.nabble.com/file/p26096793/makepath.c.diff makepath.c.diff http://www.nabble.com/file/p26096793/test.tar.gz test.tar.gz
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.

Amardeep Chana
Indiana, US

reply via email to

[Prev in Thread] Current Thread [Next in Thread]