Nabble - Gnu - Cpio

Re: cpio causing problem with pkgadd installation.

2009-12-17T08:12:49Z

hichem badsi <badhichem@...> ha escrit:

> when trying to install package using "pkgadd" command i have the

pkgadd is not the part of GNU cpio.

> following error on SunOS 5.10 Generic_118833-17 sun4u sparc
> SUNW,Sun-Fire-V440:
> cpio: bad magic number/header

That's not GNU cpio. GNU cpio does not issue such diagnostic message.
Please direct your questions to the authors of the cpio program you
use.

Regards,
Sergey

cpio causing problem with pkgadd installation.

2009-12-15T03:34:05Z

hello,
when trying to install package using "pkgadd" command i have the following error on SunOS 5.10 Generic_118833-17 sun4u sparc SUNW,Sun-Fire-V440:

cpio: bad magic number/header
1 errors
pkgadd: ERROR: attempt to process datastream failed
- process </usr/bin/cpio -icdumD -C 512> failed exit code 1
pkgadd: ERROR: unable to unpack datastream

please can you explain me the meaning of this probleme and how can i solve it !

THANK YOU.

GNU cpio unable to write to rmt tape

2009-12-10T14:51:07Z

GNU cpio unable to write to rmt tape

I get this error Immediately when I try to write to the /dev/rmt0 tape.
This is an AIX5.1 system
rmt0 is scsi (36/72mm tape)

[ballycs@ACDemo_sdsA /usr/projects/sds/10,99] su -c "find * -print | cpio -ov > /dev/rmt0"
root's Password:
Found end of tape. To continue, type device/file name when ready.

Bruce McDaniel
Programmer/Analyst
Gaming Products Support
Atlantic City Corporate IT Department
2100 Pacific Avenue
2nd Fl. Colisseum Garage
Atlantic City, NJ 08401
Office: (609)343-2639
Fax : (609)343-2682

"We are not retreating -- we are advancing in another direction." -- General Douglas MacArthur

Re: Bug#557437: no mention of how to turn on/off escaping for -t/-tv

2009-11-26T15:16:59Z

forcemerge 557437 416701
thanks
CA> I think this is the same as #416701, no?
Hmmm... and it even says on 416701 that it was to be fixed...

Bug#558149: document cpio -t OK without -i

2009-11-26T10:52:04Z

Package: cpio
Version: 2.10-1
Severity: wishlist
X-debbugs-cc: bug-cpio@...

The man and info pages make it look like -t is illegal to use by itself,
and needs an accompanying -i.

Perhaps the Info page could mention in its -t discussion that -i need
not necessarily be used with it in fact.

Bug#557437: no mention of how to turn on/off escaping for -t/-tv

2009-11-21T10:05:25Z

Package: cpio
Version: 2.10-1
X-debbugs-cc: bug-cpio@...
Severity: wishlist

Regarding
`-v'
`--verbose'
List the files processed, or with `-t', give an `ls -l' style
table of contents listing. In a verbose table of contents of a
ustar archive, user and group names in the archive that do not
exist on the local system are replaced by the names that
correspond locally to the numeric UID and GID stored in the
archive.

However, verbose has another effect,
$ <f cpio -t 980731/QGIS/登革熱02-09.shx
980731/QGIS/登革熱02-09.shx
103896 blocks
$ <f cpio -vt 980731/QGIS/登革熱02-09.shx
-rw-r--r-- 1 jidanni jidanni 2964 Jul 22 22:37 980731/QGIS/\265n\255\262\274\36602-09.shx
103896 blocks

As you see, it escapes the filenames.

And there is no documentation on how to turn off this effect.

Nor how to turn it on for just plain -t.

At least document (there at -v on the man page) that there is this
effect -- and that there is no way to turn it on or off.

[PATCH] Fix creation of newc/crc archives with files containing multiple hard links

2009-11-19T16:05:32Z

* src/copyout.c (count_defered_links_to_dev_ino): Make return type
unsigned. Fix local variable types to match cpio_file_stat members
types.
(last_link): Make link count type unsigned.
(writeout_other_defers): Fix local variable types to match
cpio_file_stat members types.
(writeout_final_defers): Make link count type unsigned.
---
If a hardlink that was going to be archived had an inode number greater
than MAX_INT, it was archived as an empty file.

src/copyout.c | 20 ++++++++++----------
1 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/src/copyout.c b/src/copyout.c
index dd9bac2..22a4313 100644
--- a/src/copyout.c
+++ b/src/copyout.c
@@ -106,14 +106,14 @@ struct deferment *deferouts = NULL;
/* Count the number of other (hard) links to this file that have
already been defered. */

-static int
+static unsigned int
count_defered_links_to_dev_ino (struct cpio_file_stat *file_hdr)
{
struct deferment *d;
- int ino;
- int maj;
- int min;
- int count;
+ ino_t ino;
+ long maj;
+ long min;
+ unsigned int count;
ino = file_hdr->c_ino;
maj = file_hdr->c_dev_maj;
min = file_hdr->c_dev_min;
@@ -133,7 +133,7 @@ count_defered_links_to_dev_ino (struct cpio_file_stat *file_hdr)
static int
last_link (struct cpio_file_stat *file_hdr)
{
- int other_files_sofar;
+ unsigned int other_files_sofar;

other_files_sofar = count_defered_links_to_dev_ino (file_hdr);
if (file_hdr->c_nlink == (other_files_sofar + 1) )
@@ -167,9 +167,9 @@ writeout_other_defers (struct cpio_file_stat *file_hdr, int out_des)
{
struct deferment *d;
struct deferment *d_prev;
- int ino;
- int maj;
- int min;
+ ino_t ino;
+ long maj;
+ long min;
ino = file_hdr->c_ino;
maj = file_hdr->c_dev_maj;
min = file_hdr->c_dev_min;
@@ -255,7 +255,7 @@ static void
writeout_final_defers (int out_des)
{
struct deferment *d;
- int other_count;
+ unsigned int other_count;
while (deferouts != NULL)
{
d = deferouts;
--
ldv

Re: Directory ownership lost in 2.9 and 2.10 when dir not empty

2009-10-30T10:19:04Z

Tim Kientzle wrote:

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.)

Cheers,

Tim

Hi Tim,

Thanks for clarifying the purpose. I had suspected it was something along those lines after reading some previous messages related to this problem. It didn't originally occur to me because I always use the -depth option to find, which puts the directory after its contents. Incidentally, the chmod 555 test did not prevent the patched cpio from restoring the tree because the directory itself was processed after the contents.

I think I've come up with a solution that would handle all possible cases (directory item precedes contents, directory item follows contents, and directory item is not present at all). It would involve generating the delayed list entries (including the properties as you suggest) from the directory item in the archive stream rather than from the implicit creation by make_path(). That way the restored directory will be created using umask thus guaranteeing the contents will be writable. In the two cases where the directory entry is in the archive stream the permissions will be restored to original after all the files. In the case where there is no directory item in the stream, they will remain as the default umask settings.

Perhaps that was the original intent! I'll post a patch when it is ready.

Thanks,
Amardeep

Re: Directory ownership lost in 2.9 and 2.10 when dir not empty

2009-10-30T08:38:21Z

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.)

Cheers,

Tim

asc1000 wrote:

>
> Reuti wrote:
>> Hi,
>>
>> 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
>>
>>
>
>
> Hello,
>
> 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:
>
> test/
> test/one/
> test/two/
> test/three/
> test/three/file
>
> 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:
>
> test/
> test/three/
>
> 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.
>
> Thanks,
> Amardeep Chana
> Indiana, US
>

Re: Directory ownership lost in 2.9 and 2.10 when dir not empty

2009-10-28T08:32:46Z

Reuti wrote:

Hi,

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

Hello,

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.

makepath.c.diff
test.tar.gz

The simple test case directory tree:

test/
test/one/
test/two/
test/three/
test/three/file

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:

test/
test/three/

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.

Thanks,
Amardeep Chana
Indiana, US

missing call to fclose in copyin.c

2009-10-19T05:36:15Z

We've received the following report from a reporter:
https://bugzilla.novell.com/show_bug.cgi?id=543132 :

--------------------
source code file cpio-2.10/src/copyin.c
function process_copy_in
local variable tty_out.

I notice the following code

tty_out = fopen (TTY_NAME, "w");

but I fail to notice a matching call to fclose. This looks like a resource
leak to me. Suggest add call to fclose near the end of the function.
--------------------

I also attach suggested fix from Robert Schweikert

thanks

[cpio-2.10-close_files_after_copy.patch]

Index: src/copyin.c =================================================================== --- src/copyin.c.orig +++ src/copyin.c @@ -1565,6 +1565,19 @@ process_copy_in () if (dot_flag) fputc ('\n', stderr); + if (tty_in) + { + fclose(tty_in); + } + if (tty_out) + { + fclose(tty_out); + } + if (rename_in) + { + fclose(rename_in); + } + if (append_flag) return;

Directory ownership lost in 2.9 and 2.10 when dir not empty

2009-10-11T06:04:46Z

Hi,

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

Re: Consistently use ino_t to support filesystems with inodes wider than 32 bits.

2009-10-07T06:59:44Z

Hello Tim, Stephen,

> FYI, this won't work on Windows (in case you care ;-):

None of the cpio headers is able to keep 64 bit inode numbers anyways.
But the patch makes the code a lot more readable, so I'll apply it.

Thanks & regards,
Sergey

(no subject)

2009-10-07T05:50:46Z

Tim Kientzle wrote:
>FYI, this won't work on Windows (in case you care ;-):
>Microsoft's ino_t is only 16 bits, even though NTFS
>uses a 64-bit index value. int64_t may be a better choice.

Is int64_t a POSIX defined type?
In any case, cpio gets the value from the stat struct. So ultimately the
question then becomes: what type does the member in the stat struct have?
Shouldn't this be ino_t by definition? And isn't it then equally useless
(on Windows) to take that value and store it in cpio?
--
Sincerely,
Stephen R. van den Berg.

"A man, a plan, a canal -- Panama!" -- The Palindromist

Re: Consistently use ino_t to support filesystems with inodes wider than 32 bits.

2009-10-05T14:11:48Z

FYI, this won't work on Windows (in case you care ;-):
Microsoft's ino_t is only 16 bits, even though NTFS
uses a 64-bit index value. int64_t may be a better choice.

Cheers,

Tim Kientzle

On Thu, Oct 1, 2009 at 11:35 AM, Stephen R. van den Berg <srb@...> wrote:

---

Add support for filesystems with inode-fields wider than 32-bits (I witnessed
this bug on a large XFS filesystem).
This patch fixes the bug that hardlinked files are *not* included at
all (i.e. both files are listed, but the content is not transmitted with
either of them).

The patch is relative to the bleeding edge version of cpio on the git
repostory.

src/copyin.c | 8 ++++----
src/copyout.c | 4 ++--
src/copypass.c | 2 +-
src/extern.h | 6 +++---
src/util.c | 6 +++---
5 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/src/copyin.c b/src/copyin.c
index 5b7594b..8ba2bc9 100644
--- a/src/copyin.c
+++ b/src/copyin.c
@@ -258,7 +258,7 @@ create_defered_links (struct cpio_file_stat *file_hdr)
{
struct deferment *d;
struct deferment *d_prev;
- int ino;
+ ino_t ino;
int maj;
int min;
int link_res;
@@ -306,7 +306,7 @@ create_defered_links_to_skipped (struct cpio_file_stat *file_hdr,
{
struct deferment *d;
struct deferment *d_prev;
- int ino;
+ ino_t ino;
int maj;
int min;
if (file_hdr->c_filesize == 0)
@@ -1460,8 +1460,8 @@ process_copy_in ()
struct cpio_file_stat *h;
h = &file_hdr;
fprintf (stderr,
- "magic = 0%o, ino = %d, mode = 0%o, uid = %d, gid = %d\n",
- h->c_magic, h->c_ino, h->c_mode, h->c_uid, h->c_gid);
+ "magic = 0%o, ino = %ld, mode = 0%o, uid = %d, gid = %d\n",
+ h->c_magic, (long)h->c_ino, h->c_mode, h->c_uid, h->c_gid);
fprintf (stderr,
"nlink = %d, mtime = %d, filesize = %d, dev_maj = 0x%x\n",
h->c_nlink, h->c_mtime, h->c_filesize, h->c_dev_maj);
diff --git a/src/copyout.c b/src/copyout.c
index dd9bac2..b3bb0ad 100644
--- a/src/copyout.c
+++ b/src/copyout.c
@@ -110,7 +110,7 @@ static int
count_defered_links_to_dev_ino (struct cpio_file_stat *file_hdr)
{
struct deferment *d;
- int ino;
+ ino_t ino;
int maj;
int min;
int count;
@@ -167,7 +167,7 @@ writeout_other_defers (struct cpio_file_stat *file_hdr, int out_des)
{
struct deferment *d;
struct deferment *d_prev;
- int ino;
+ ino_t ino;
int maj;
int min;
ino = file_hdr->c_ino;
diff --git a/src/copypass.c b/src/copypass.c
index 8941b76..20929a6 100644
--- a/src/copypass.c
+++ b/src/copypass.c
@@ -387,7 +387,7 @@ process_copy_pass ()

int
link_to_maj_min_ino (char *file_name, int st_dev_maj, int st_dev_min,
- int st_ino)
+ ino_t st_ino)
{
int link_res;
char *link_name;
diff --git a/src/extern.h b/src/extern.h
index a832897..6144be1 100644
--- a/src/extern.h
+++ b/src/extern.h
@@ -119,7 +119,7 @@ void process_copy_out (void);
/* copypass.c */
void process_copy_pass (void);
int link_to_maj_min_ino (char *file_name, int st_dev_maj,
- int st_dev_min, int st_ino);
+ int st_dev_min, ino_t st_ino);
int link_to_name (char *link_name, char *link_target);

/* dirname.c */
@@ -169,9 +169,9 @@ void warn_if_file_changed (char *file_name, off_t old_file_size,
time_t old_file_mtime);
void create_all_directories (char *name);
void prepare_append (int out_file_des);
-char *find_inode_file (unsigned long node_num,
+char *find_inode_file (ino_t node_num,
unsigned long major_num, unsigned long minor_num);
-void add_inode (unsigned long node_num, char *file_name,
+void add_inode (ino_t node_num, char *file_name,
unsigned long major_num, unsigned long minor_num);
int open_archive (char *file);
void tape_offline (int tape_des);
diff --git a/src/util.c b/src/util.c
index 1eb92ae..16a4320 100644
--- a/src/util.c
+++ b/src/util.c
@@ -686,7 +686,7 @@ prepare_append (int out_file_des)

struct inode_val
{
- unsigned long inode;
+ ino_t inode;
unsigned long major_num;
unsigned long minor_num;
char *file_name;
@@ -713,7 +713,7 @@ inode_val_compare (const void *val1, const void *val2)
}

char *
-find_inode_file (unsigned long node_num, unsigned long major_num,
+find_inode_file (ino_t node_num, unsigned long major_num,
unsigned long minor_num)
{
struct inode_val sample;
@@ -732,7 +732,7 @@ find_inode_file (unsigned long node_num, unsigned long major_num,
/* Associate FILE_NAME with the inode NODE_NUM. (Insert into hash table.) */

void
-add_inode (unsigned long node_num, char *file_name, unsigned long major_num,
+add_inode (ino_t node_num, char *file_name, unsigned long major_num,
unsigned long minor_num)
{
struct inode_val *temp;
--
1.6.2.151.gdc0be

--
Sincerely,
Stephen R. van den Berg.

"If he learns from his mistakes, pretty soon he'll know everything."

Consistently use ino_t to support filesystems with inodes wider than 32 bits.

2009-10-01T11:35:20Z

---

Add support for filesystems with inode-fields wider than 32-bits (I witnessed
this bug on a large XFS filesystem).
This patch fixes the bug that hardlinked files are *not* included at
all (i.e. both files are listed, but the content is not transmitted with
either of them).

The patch is relative to the bleeding edge version of cpio on the git
repostory.

src/copyin.c | 8 ++++----
src/copyout.c | 4 ++--
src/copypass.c | 2 +-
src/extern.h | 6 +++---
src/util.c | 6 +++---
5 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/src/copyin.c b/src/copyin.c
index 5b7594b..8ba2bc9 100644
--- a/src/copyin.c
+++ b/src/copyin.c
@@ -258,7 +258,7 @@ create_defered_links (struct cpio_file_stat *file_hdr)
{
struct deferment *d;
struct deferment *d_prev;
- int ino;
+ ino_t ino;
int maj;
int min;
int link_res;
@@ -306,7 +306,7 @@ create_defered_links_to_skipped (struct cpio_file_stat *file_hdr,
{
struct deferment *d;
struct deferment *d_prev;
- int ino;
+ ino_t ino;
int maj;
int min;
if (file_hdr->c_filesize == 0)
@@ -1460,8 +1460,8 @@ process_copy_in ()
struct cpio_file_stat *h;
h = &file_hdr;
fprintf (stderr,
- "magic = 0%o, ino = %d, mode = 0%o, uid = %d, gid = %d\n",
- h->c_magic, h->c_ino, h->c_mode, h->c_uid, h->c_gid);
+ "magic = 0%o, ino = %ld, mode = 0%o, uid = %d, gid = %d\n",
+ h->c_magic, (long)h->c_ino, h->c_mode, h->c_uid, h->c_gid);
fprintf (stderr,
"nlink = %d, mtime = %d, filesize = %d, dev_maj = 0x%x\n",
h->c_nlink, h->c_mtime, h->c_filesize, h->c_dev_maj);
diff --git a/src/copyout.c b/src/copyout.c
index dd9bac2..b3bb0ad 100644
--- a/src/copyout.c
+++ b/src/copyout.c
@@ -110,7 +110,7 @@ static int
count_defered_links_to_dev_ino (struct cpio_file_stat *file_hdr)
{
struct deferment *d;
- int ino;
+ ino_t ino;
int maj;
int min;
int count;
@@ -167,7 +167,7 @@ writeout_other_defers (struct cpio_file_stat *file_hdr, int out_des)
{
struct deferment *d;
struct deferment *d_prev;
- int ino;
+ ino_t ino;
int maj;
int min;
ino = file_hdr->c_ino;
diff --git a/src/copypass.c b/src/copypass.c
index 8941b76..20929a6 100644
--- a/src/copypass.c
+++ b/src/copypass.c
@@ -387,7 +387,7 @@ process_copy_pass ()

int
link_to_maj_min_ino (char *file_name, int st_dev_maj, int st_dev_min,
- int st_ino)
+ ino_t st_ino)
{
int link_res;
char *link_name;
diff --git a/src/extern.h b/src/extern.h
index a832897..6144be1 100644
--- a/src/extern.h
+++ b/src/extern.h
@@ -119,7 +119,7 @@ void process_copy_out (void);
/* copypass.c */
void process_copy_pass (void);
int link_to_maj_min_ino (char *file_name, int st_dev_maj,
- int st_dev_min, int st_ino);
+ int st_dev_min, ino_t st_ino);
int link_to_name (char *link_name, char *link_target);

/* dirname.c */
@@ -169,9 +169,9 @@ void warn_if_file_changed (char *file_name, off_t old_file_size,
time_t old_file_mtime);
void create_all_directories (char *name);
void prepare_append (int out_file_des);
-char *find_inode_file (unsigned long node_num,
+char *find_inode_file (ino_t node_num,
unsigned long major_num, unsigned long minor_num);
-void add_inode (unsigned long node_num, char *file_name,
+void add_inode (ino_t node_num, char *file_name,
unsigned long major_num, unsigned long minor_num);
int open_archive (char *file);
void tape_offline (int tape_des);
diff --git a/src/util.c b/src/util.c
index 1eb92ae..16a4320 100644
--- a/src/util.c
+++ b/src/util.c
@@ -686,7 +686,7 @@ prepare_append (int out_file_des)

struct inode_val
{
- unsigned long inode;
+ ino_t inode;
unsigned long major_num;
unsigned long minor_num;
char *file_name;
@@ -713,7 +713,7 @@ inode_val_compare (const void *val1, const void *val2)
}

char *
-find_inode_file (unsigned long node_num, unsigned long major_num,
+find_inode_file (ino_t node_num, unsigned long major_num,
unsigned long minor_num)
{
struct inode_val sample;
@@ -732,7 +732,7 @@ find_inode_file (unsigned long node_num, unsigned long major_num,
/* Associate FILE_NAME with the inode NODE_NUM. (Insert into hash table.) */

void
-add_inode (unsigned long node_num, char *file_name, unsigned long major_num,
+add_inode (ino_t node_num, char *file_name, unsigned long major_num,
unsigned long minor_num)
{
struct inode_val *temp;
--
1.6.2.151.gdc0be

--
Sincerely,
Stephen R. van den Berg.

"If he learns from his mistakes, pretty soon he'll know everything."

Re: cpio suggestion: --quick-exit

2009-08-23T11:41:19Z

Tim,

Thanks for the feedback.

I don't think --occurrence is equivalent to what I'm trying to achieve, as it
sounds like cpio would still have to read the entire archive (which is what
I'm trying to avoid) if a wildcard is specified.

It sounds like my --quick-exit is of the same vein as --fast-read. However,
the description provided sounds to me (I'm no expert by any means) like if I
requested a restore of "home/carl/*" using --fast-read then I'd only get the
first file matched (not the entire subtree) which is not what I'm looking
for. If this is an incorrect interpretation, then I think the two are the
same, and using --fast-read instead of --quick-exit in cpio is fine with me.
(Although, IMHO, --quick-exit more aptly describes its function...)

I am also not familiar with all of the flavors of tar, so I do not know how
directories are visited in each. But then again, cpio doesn't even do tree
traversal (you have to feed it file names to back up). This option could be
available for archives that have been purposefully structured to take
advantage of it, like my full and daily backups.

I'm somewhat baffled by the "rife for confusion" remark. I think it could be
explained quite suscinctly: "If a wildcard is used to specify the files to
be restored and --quick-exit [for --fast-read] is specified, the archive will
be read until the first file matches. Subsequent files will be restored
until the path up to the wildcard specification changes in the archive, at
which point cpio will exit unless there are other paths specified on the
command line that have not been restored. For example..."

Is there a design philosophy for cpio that it remain as close to tar in
command line options and mode of operation as possible? I realize the
benefit of this consistency, but they are different programs, after all...

Anyway, it sounds like this is a do-able change. Any other comments,
suggestions, or pointers as to how I might proceed?

Thanks,

Carl

On Saturday, August 22, 2009, Tim Kientzle wrote:

> Carl Sopchak wrote:
> > Hi,
> >
> > This is a suggestion for a new option to cpio, --quick-exit. The purpose
> > of the option is to exit cpio as soon as the requested file(s) have been
> > restored, instead of reading all the way through the archive.
>
> Perhaps it would be better to implement the GNU tar --occurrence
> option:
>
> --occurrence[=NUMBER]
> process only the NUMBERth occurrence of each file
> in the archive; this option is valid only in
> conjunction with one of the subcommands --delete,
> --diff, --extract or --list and when a list of
> files is given either on the command line or via
> the -T option; NUMBER defaults to 1
>
> or the older --fast-read aka -q supported by FreeBSD's
> tar (which used to be a patched GNU tar, since replaced
> by bsdtar):
>
> -q (--fast-read)
> (x and t mode only) Extract or list only the first archive entry
> that matches each pattern or filename operand. Exit as soon as
> each specified pattern or filename has been matched. By default,
> the archive is always read to the very end, since there can be
> multiple entries with the same name and, by convention, later
> entries overwrite earlier entries. This option is provided as a
> performance optimization.
>
> Your notion of allowing this to work for specifying a directory
> (exiting as soon as something outside of the directory is seen)
> sounds rife for confusion, though. Besides append operation,
> it's a little dangerous to make strong assumptions about the
> order in which items are written into archives. (Witness the
> very different orders that GNU tar, star, and bsdtar use
> for visiting directories.)
>
> Tim

Re: cpio suggestion: --quick-exit

2009-08-22T17:55:21Z

Carl Sopchak wrote:
> Hi,
>
> This is a suggestion for a new option to cpio, --quick-exit. The purpose of
> the option is to exit cpio as soon as the requested file(s) have been
> restored, instead of reading all the way through the archive.

Perhaps it would be better to implement the GNU tar --occurrence
option:

--occurrence[=NUMBER]
process only the NUMBERth occurrence of each file
in the archive; this option is valid only in
conjunction with one of the subcommands --delete,
--diff, --extract or --list and when a list of
files is given either on the command line or via
the -T option; NUMBER defaults to 1

or the older --fast-read aka -q supported by FreeBSD's
tar (which used to be a patched GNU tar, since replaced
by bsdtar):

-q (--fast-read)
(x and t mode only) Extract or list only the first archive entry
that matches each pattern or filename operand. Exit as soon as
each specified pattern or filename has been matched. By default,
the archive is always read to the very end, since there can be
multiple entries with the same name and, by convention, later
entries overwrite earlier entries. This option is provided as a
performance optimization.

Your notion of allowing this to work for specifying a directory
(exiting as soon as something outside of the directory is seen)
sounds rife for confusion, though. Besides append operation,
it's a little dangerous to make strong assumptions about the
order in which items are written into archives. (Witness the
very different orders that GNU tar, star, and bsdtar use
for visiting directories.)

Tim

cpio suggestion: --quick-exit

2009-08-21T11:18:11Z

Hi,

This is a suggestion for a new option to cpio, --quick-exit. The purpose of
the option is to exit cpio as soon as the requested file(s) have been
restored, instead of reading all the way through the archive. The theory
behind it is that the archive is more or less organized by directory, and
once you pass the end of a directory in the archive, it won't appear again.
This obviously assumes that the --append option wasn't used. If it was with
the archive (or if you didn't know), you would not use the --quick-exit
option. Also, it would only be useful if a wildcard character in the file(s)
to be restored were at least one directory down from the root of the archive,
or if there were no wildcard characters at all.

For example, if cpio was invoked with
cpio --extract --quick-exit "home/carl/*"
cpio would scan the archive until it came to the home/carl directory, restore
all of the contents of that directly, then immediately exit.

To be honest, I'm kinda suprised that this hasn't been though of before. Is
there a reason why this would be impractical to implement?

I would consider implementing this option, as it would benefit me, but I would
need someone to point me in the right direction...

Thanks for the consideration,

Carl

Re: Re: Bug#325989: cpio: -iv reports filename when "newer or same age version exists"

2009-07-31T07:47:45Z

Clint Adams <schizo@...> ha escrit:

> > With 2.5-1.2 and before, the line "foo" was not present. Only
> > files actually copied should be reported.

This behavior is consistent with that of GNU tar.

Regards,
Sergey

Re: Re: Bug#458079: cpio 2.9.90-2

2009-07-31T07:46:25Z

Clint Adams <schizo@...> ha escrit:

> This behavior also applies to cpio 2.10

Fixed in the repository.

Regards,
Sergey

cpio-2.10.90 (alpha) available

2009-07-31T02:59:44Z

Hello,

Please be informed that a new alpha version of cpio (cpio-2.10.90) is
available for download from ftp://alpha.gnu.org/gnu/cpio.
This version fixes build problems discovered recently
by Peter Breitenlohner.

Here are the compressed sources:
ftp://alpha.gnu.org/gnu/cpio/cpio-2.10.90.tar.gz (1.3MB)
ftp://alpha.gnu.org/gnu/cpio/cpio-2.10.90.tar.bz2 (929KB)

Here are the GPG detached signatures[*]:
ftp://alpha.gnu.org/gnu/cpio/cpio-2.10.90.tar.gz.sig
ftp://alpha.gnu.org/gnu/cpio/cpio-2.10.90.tar.bz2.sig

Here are the MD5 and SHA1 checksums:

f5a2733acd0f7ce32df427b72ada10a9 cpio-2.10.90.tar.gz
213f6a0ecdcd3d3512ce23e43bdccf67 cpio-2.10.90.tar.bz2
b72e037d2dc34d795e2e8e30a806484832019276 cpio-2.10.90.tar.gz
a56bd3f80a33181318e87967afa9116a952bcfe0 cpio-2.10.90.tar.bz2

[*] You can use either of the above signature files to verify that
the corresponding file (without the .sig suffix) is intact. First,
be sure to download both the .sig file and the corresponding tarball.
Then, run a command like this:

gpg --verify cpio-2.10.90.tar.gz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

gpg --keyserver keys.gnupg.net --recv-keys 55D0C732

and rerun the `gpg --verify' command.

This release was bootstrapped with the following tools:
Autoconf 2.63
Automake 1.11
Gnulib-tool 0.0.2231-836f3
Makeinfo 4.13

Regards,
Sergey

Re: cpio-2.10 -- building mt fails badly

2009-07-31T02:00:21Z

On Fri, 31 Jul 2009, Sergey Poznyakoff wrote:

>> my attempt to build mt as part of cpio-2.10 failed badly:
>
> Thanks for reporting. Please, apply the attached patch.

Hi Sergey,

works nicely. Thanks for your quick answer.

Regards
Peter

Re: cpio-2.10 -- building mt fails badly

2009-07-31T00:45:29Z

Peter Breitenlohner <peb@...> ha escrit:

> my attempt to build mt as part of cpio-2.10 failed badly:

Thanks for reporting. Please, apply the attached patch.

Regards,
Sergey

diff --git a/src/mt.c b/src/mt.c
index 5d128a9..e0a3883 100644
--- a/src/mt.c
+++ b/src/mt.c
@@ -73,7 +73,7 @@
#include <stdbool.h>

#ifdef HAVE_LOCALE_H
-# include <locale.h>
+# include <locale.h>
#endif
#include <rmt-command.h>

@@ -105,10 +105,27 @@ int atoi ();
void exit ();
#endif

-char *opnames[] =
+#include <argmatch.h>
+#include <paxlib.h>
+#include "configmake.h"
+
+#define MT_EXIT_SUCCESS 0
+#define MT_EXIT_INVOP 1
+#define MT_EXIT_FAILURE 2
+
+char const * const opnames[] =
{
- "eof", "weof", "fsf", "bsf", "fsr", "bsr",
- "rewind", "offline", "rewoffl", "eject", "status",
+ "eof",
+ "weof",
+ "fsf",
+ "bsf",
+ "fsr",
+ "bsr",
+ "rewind",
+ "offline",
+ "rewoffl",
+ "eject",
+ "status",
#ifdef MTBSFM
"bsfm",
#endif
@@ -134,8 +151,17 @@ char *opnames[] =
#define MTASF 600 /* Random unused number. */
short operations[] =
{
- MTWEOF, MTWEOF, MTFSF, MTBSF, MTFSR, MTBSR,
- MTREW, MTOFFL, MTOFFL, MTOFFL, MTNOP,
+ MTWEOF,
+ MTWEOF,
+ MTFSF,
+ MTBSF,
+ MTFSR,
+ MTBSR,
+ MTREW,
+ MTOFFL,
+ MTOFFL,
+ MTOFFL,
+ MTNOP,
#ifdef MTBSFM
MTBSFM,
#endif
@@ -155,9 +181,10 @@ short operations[] =
#ifdef MTSEEK
MTSEEK,
#endif
- 0
};

+ARGMATCH_VERIFY (opnames, operations);
+
struct option longopts[] =
{
{"file", 1, NULL, 'f'},
@@ -180,8 +207,9 @@ check_type (char *dev, int desc)
if (fstat (desc, &stats) == -1)
stat_error (dev);
if ((stats.st_mode & S_IFMT) != S_IFCHR)
- error (1, 0, _("%s is not a character special file"), dev);
+ error (MT_EXIT_INVOP, 0, _("%s is not a character special file"), dev);
}
+
void
perform_operation (char *dev, int desc, short op, int count)
{
@@ -193,7 +221,7 @@ perform_operation (char *dev, int desc, short op, int count)
error, not 0. This bug has been reported to
"bug-gnu-utils@...". (96/7/10) -BEM */
if (rmtioctl (desc, MTIOCTOP, (char*)&control) == -1)
- error (2, errno, _("%s: rmtioctl failed"), dev);
+ error (MT_EXIT_FAILURE, errno, _("%s: rmtioctl failed"), dev);
}

void
@@ -202,7 +230,7 @@ print_status (char *dev, int desc)
struct mtget status;

if (rmtioctl (desc, MTIOCGET, (char*)&status) == -1)
- error (2, errno, _("%s: rmtioctl failed"), dev);
+ error (MT_EXIT_FAILURE, errno, _("%s: rmtioctl failed"), dev);

printf ("drive type = %d\n", (int) status.mt_type);
#if defined(hpux) || defined(__hpux)
@@ -220,7 +248,7 @@ print_status (char *dev, int desc)
}

void
-usage (FILE *fp,int status)
+usage (FILE *fp, int status)
{
fprintf (fp, _("\
Usage: %s [-V] [-f device] [--file=device] [--rsh-command=command]\n\
@@ -229,6 +257,12 @@ Usage: %s [-V] [-f device] [--file=device] [--rsh-command=command]\n\
exit (status);
}

+void
+fatal_exit ()
+{
+ exit (MT_EXIT_INVOP);
+}
+
int
main (int argc, char **argv)
{
@@ -264,23 +298,23 @@ main (int argc, char **argv)

case 'V':
printf ("mt (%s)\n", PACKAGE_STRING);
- exit (0);
+ exit (MT_EXIT_SUCCESS);
break;

case 'H':
default:
- usage (stdout, 0);
+ usage (stdout, MT_EXIT_SUCCESS);
}
}

if (optind == argc)
- usage (stderr, 1);
+ usage (stderr, MT_EXIT_INVOP);

- i = argmatch (argv[optind], opnames);
+ i = ARGMATCH (argv[optind], opnames, operations);
if (i < 0)
{
argmatch_invalid ("tape operation", argv[optind], i);
- exit (1);
+ exit (MT_EXIT_INVOP);
}
operation = operations[i];

@@ -295,7 +329,7 @@ main (int argc, char **argv)
count = atoi (argv[optind]);
#endif
if (++optind < argc)
- usage (stderr, 1);
+ usage (stderr, MT_EXIT_INVOP);

if (tapedev == NULL)
{
@@ -304,7 +338,7 @@ main (int argc, char **argv)
#ifdef DEFTAPE /* From sys/mtio.h. */
tapedev = DEFTAPE;
#else
- error (1, 0, _("no tape device specified"));
+ error (MT_EXIT_INVOP, 0, _("no tape device specified"));
#endif
}

@@ -317,7 +351,7 @@ main (int argc, char **argv)
else
tapedesc = rmtopen (tapedev, O_RDONLY, 0, rsh_command_option);
if (tapedesc == -1)
- error (1, errno, _("%s: rmtopen failed"), tapedev);
+ error (MT_EXIT_INVOP, errno, _("%s: rmtopen failed"), tapedev);
check_type (tapedev, tapedesc);

if (operation == MTASF)
@@ -330,8 +364,8 @@ main (int argc, char **argv)
print_status (tapedev, tapedesc);

if (rmtclose (tapedesc) == -1)
- error (2, errno, _("%s: rmtclose failed"), tapedev);
+ error (MT_EXIT_FAILURE, errno, _("%s: rmtclose failed"), tapedev);

- exit (0);
+ exit (MT_EXIT_SUCCESS);
}

Re: cpio-2.10 -- building mt fails badly

2009-07-30T05:37:02Z

On Thu, 30 Jul 2009, Peter Breitenlohner wrote:

>
> attached is a small patch addressing the points 1, 2, and 4.

Sorry, I forgot to attach the patch.

Regards
Peter Breitenlohner <peb@...>
diff -ur cpio-2.10.orig/src/Makefile.am cpio-2.10/src/Makefile.am
--- cpio-2.10.orig/src/Makefile.am 2009-06-19 11:24:50.000000000 +0200
+++ cpio-2.10/src/Makefile.am 2009-07-29 18:27:31.000000000 +0200
@@ -37,6 +37,10 @@
makepath.c\
userspec.c

+mt_SOURCES = \
+ fatal.c\
+ mt.c
+
noinst_HEADERS =\
cpio.h\
cpiohdr.h\
@@ -50,4 +54,4 @@

LDADD=../lib/libpax.a ../gnu/libgnu.a @INTLLIBS@

-mt.o main.o: ../lib/rmt-command.h
+mt.$(OBJEXT) main.$(OBJEXT): ../lib/rmt-command.h
diff -ur cpio-2.10.orig/src/mt.c cpio-2.10/src/mt.c
--- cpio-2.10.orig/src/mt.c 2009-02-14 19:15:50.000000000 +0100
+++ cpio-2.10/src/mt.c 2009-07-29 18:36:50.000000000 +0200
@@ -77,6 +77,9 @@
#endif
#include <rmt-command.h>

+#include "configmake.h"
+#include "paxlib.h"
+
#if defined(HAVE_UNISTD_H)
#include <unistd.h>
#endif

cpio-2.10 -- building mt fails badly

2009-07-30T05:34:41Z

Hi,

my attempt to build mt as part of cpio-2.10 failed badly:

(1) src/mt.c must include "configmake.h" in order to define LOCALEDIR
and "paxlib.h" in order to define xxx (don't remember).

(2) mt_SOURCES should be declared to include mt.c and fatal.c

according to the ChangeLog fatal.c used to be in lib/ and thus be part of
libcpio.a, why has this been changed.

(3) when compiling mt.c, there are implicit declarations of `argmatch' and
`argmatch_invalid'. I do, however, get an `mt' executable, but...

Including argmatch.h makes thing only worse because the use of argmatch in
mt.c(main) is incompatible with the definition in gnu/argmatch.[ch].

Thus the `mt' execuatble almost certainly is bad, will segfault or...

(4) a minor final item: the explicit dependency in src/Makefile.am should
use '.$(OBJEXT)' instead of '.o' (for cygwin).

==================

attached is a small patch addressing the points 1, 2, and 4.

Regards
Peter Breitenlohner <peb@...>

Re: -lnsl needed, cpio 2.10, Solaris 9

2009-06-22T00:16:44Z

Zube <Zube@...> ha escrit:

> On Solaris 9, cpio 2.10 fails to compile because it cannot find
> gethostbyname during the final link. Adding -lnsl to the LIBS line in
> src/Makefile fixes the issue.

Thanks for reporting.

Regards,
Sergey

Re: found resource leaks

2009-06-22T00:14:00Z

Hi Martin,

> [cpio-2.10/src/copyin.c:1583]: (error) Resource leak: tty_in
> [cpio-2.10/src/copyin.c:1583]: (error) Resource leak: tty_out
> [cpio-2.10/src/copyin.c:1583]: (error) Resource leak: rename_in

They will be closed when the program finishes and that happens
right after process_copy_in returns.

Regards,
Sergey

-lnsl needed, cpio 2.10, Solaris 9

2009-06-21T05:04:36Z

On Solaris 9, cpio 2.10 fails to compile because it cannot find
gethostbyname during the final link. Adding -lnsl to the LIBS line in
src/Makefile fixes the issue.

Cheers,
Zube

found resource leaks

2009-06-20T16:46:42Z

Hi all,

i have checked the sources of the cpio-2.10 library with the static code analysis tool cppcheck. It found little issues:

[cpio-2.10/src/copyin.c:1583]: (error) Resource leak: tty_in
[cpio-2.10/src/copyin.c:1583]: (error) Resource leak: tty_out
[cpio-2.10/src/copyin.c:1583]: (error) Resource leak: rename_in

Take a loop at file copyin.c at line 1583:
....
}

The function ends without flcose the opened file pointers. A possible fix might be :

...
if(tty_in!=NULL) fclose(tty_in);
if(tty_out!=NULL) fclose(tty_out);
if(rename_in!=NULL) fclose(rename_in);
...

Best regards

Ettl Martin

--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Re: Bug#325989: cpio: -iv reports filename when "newer or same age version exists"

2009-06-20T11:58:30Z

This behavior also applies to cpio 2.10.

On Wed, Aug 31, 2005 at 09:57:15PM -0700, W M Brelsford wrote:

> Beginning with 2.6-3 (2.6-1?):
>
> $ touch foo
>
> $ ls foo | cpio -o >foo.cpio
> 1 block
>
> $ cpio -iv <foo.cpio
> cpio: foo not created: newer or same age version exists
> foo
> 1 block
>
> With 2.5-1.2 and before, the line "foo" was not present. Only
> files actually copied should be reported.

Re: Bug#458079: cpio 2.9.90-2

2009-06-20T11:57:21Z

This behavior also applies to cpio 2.10

On Wed, Mar 04, 2009 at 08:10:18AM +0100, Dietmar Schroeter wrote:

> Unfortunately it is, at least in cpio_2.9.90-3 .
> For your convenience, I append the modified testscript, which
> delivers a definite yes or no as you can see in this example:
>
> $ pwd
> /root/cpio
> $ ./cpio-bug
> 1 block
> 1 block
> drwx------
> bad: bug still present in cpio
> 1 block
> 1 block
> drwx------
> bad: bug still present in /root/cpio/cpio
> 1 block
> 1 block
> drwxr-xr-x
> good: bug not found in /root/cpio/cpio-etch
>
> And here comes the script (does not need root permissions):
>
> #!/bin/sh
> cpio_bugtest()
> {
> typeset cpioprog="$1"
>
> case "$cpioprog" in
> /*) ;;
> "") cpioprog=cpio # the system default
> ;;
> *) echo "please specify an absolute path for cpioprog" >&2
> return 1
> ;;
> esac
> testdir="$(mktemp -d)" || return 11
> trap "rm -rf $testdir" 0
> umask 077
> rm -rf wrongperms newdir
> mkdir -m 755 "$testdir/wrongperms"
> >"$testdir/wrongperms/file"
> mkdir "$testdir/newdir"
> (cd "$testdir" && find wrongperms -depth | "$cpioprog" -oH newc) | (cd "$testdir/newdir" && "$cpioprog" -imd)
> #ls -laR "$testdir/wrongperms"
> #ls -laR "$testdir/newdir"
> perms="$(ls -ld "$testdir/newdir/wrongperms")"
> perms="${perms%% *}"
> echo "$perms"
> case "$perms" in
> "drwx------") echo "bad: bug still present in $cpioprog" >&2
> rm -rf "$testdir"
> trap "" 0
> return 1
> ;;
> "drwxr-xr-x") echo "good: bug not found in $cpioprog" >&2
> rm -rf "$testdir"
> trap "" 0
> return 0
> ;;
> *) echo "sorry: unknown state. Please debug testscript :-(" >&2
> rm -rf "$testdir"
> trap "" 0
> return 1
> ;;
> esac
> }
> cpio_bugtest
> cpio_bugtest $PWD/cpio
> cpio_bugtest $PWD/cpio-etch
> exit
>
> ### end of script ###
>
> Regards
> Dietmar

GNU cpio 2.10

2009-06-20T01:55:17Z

Hello,

I am glad to announce the release of GNU cpio 2.10.

GNU cpio copies files into or out of a cpio or tar archive. It supports
various archive formats, among them: binary, ASCII (both old and new),
crc, HPUX binary, HPUX old ASCII, old tar, POSIX.1 tar. When extracting
from archives, cpio automatically recognizes which kind of archive it is
reading and can read archives created on machines with a different
byte-order.

This release contains several bugfixes and improvements, among them:

* Ensure record headers are properly packed (fix builds on ARM).
* Fix exit codes to reliably indicate success or failure of the operation.
* Fix large file support.
* Support MinGW builds.

I'd like to express my special thanks to Robert Millan, Clint Adams and
Ladislav Michnovic for their reports, patches and suggestions.

For more information on cpio, including links to file downloads,
please see the GNU cpio web page: http://www.gnu.org/software/cpio
and the the project page http://savannah.gnu.org/projects/cpio.

Please email bugs or suggestions to <bug-cpio@...>.

Here are the compressed sources:
ftp://ftp.gnu.org/gnu/cpio/cpio-2.10.tar.gz (1.3MB)
ftp://ftp.gnu.org/gnu/cpio/cpio-2.10.tar.bz2 (932KB)

Here are the GPG detached signatures[*]:
ftp://ftp.gnu.org/gnu/cpio/cpio-2.10.tar.gz.sig
ftp://ftp.gnu.org/gnu/cpio/cpio-2.10.tar.bz2.sig

Here are the MD5 and SHA1 checksums:

351ab3d38d8949913e478cc23b9d6ad4 cpio-2.10.tar.gz
edd8d956a5dfb9a3b308fa07f302f691 cpio-2.10.tar.bz2
3d4639351b3c7a782e2a62db3645e756ca1f4614 cpio-2.10.tar.gz
a87f85c23697163000c656db9eb26a348aa3397b cpio-2.10.tar.bz2

[*] You can use either of the above signature files to verify that
the corresponding file (without the .sig suffix) is intact. First,
be sure to download both the .sig file and the corresponding tarball.
Then, run a command like this:

gpg --verify cpio-2.10.tar.gz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

gpg --keyserver keys.gnupg.net --recv-keys 55D0C732

and rerun the `gpg --verify' command.

This release was bootstrapped with the following tools:
Autoconf 2.63
Automake 1.11
Gnulib-tool 0.0.2213-b7976
Makeinfo 4.13

Regards,
Sergey

Re: grouping options

2009-06-06T16:17:25Z

At the top of (info "(cpio)Options")
say "To see a grouped list of these, use cpio --help."

It would be better to improve the manual.

Re: Bug-cpio lost timestamp and lost owner in 2.9

2009-06-06T00:08:27Z

Hi Clint,

My apologies, I got terribly behind the schedule. I'm working on
the new release and expect to make it ready next week. This time
for sure :)

Regards,
Sergey