bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Extensions to Tar


From: Paul Eggert
Subject: Re: Extensions to Tar
Date: Wed, 3 Apr 2002 15:28:51 -0800 (PST)

> Date: Sun, 31 Mar 2002 13:04:36 +0100 (BST)
> From: Chris Wilson <address@hidden>

> > Look at the 'pax' command for a description of the format.
> 
> I've had a look at this document, and it says that A-Z typeflags are 
> reserved for custom implementations. I noticed that all the GNUTYPE_* 
> typeflags were also in the A-Z range with a similar comment, and that Y 
> and E were unused, so I added mine to that list. Is that okay?

It's OK as far as I know, but it would be helpful if you looked for
other software to see what it did with those letters.  I would look at
the letters that the latest 'star' uses, for example.

ftp://ftp.fokus.gmd.de/pub/unix/star/alpha/star-1.4a21.tar.gz

> 
> > With ssh you can give them only the ability to run a certain command,
> > presumably rmt or a wrapper for rmt.  Isn't that enough to give you
> > want you want?
> 
> Maybe, I'll look into it. The main problem is that it doesn't work for 
> multi-volume file archives

Doesn't rmt have the same problem?  I don't see why a wrapper would fail
for multi-volume files, if plain rmt succeeds.

> > You should be able to do that by telling tar to read
> > the archive from stdin and write it to stdout, updating as you go.
> 
> How do I tell tar to do that?

tar -u -f -

It's not much used, though, and it could well be buggy.

> > Why?  You don't trust the time stamps?
> 
> That's why I ask. I know rsync uses checksums (md5 I think) to compare 
> files, and I know programs like tar can restore an archive and fudge the 
> timestamps so it wouldn't be backed up by an incremental restore. Or am I 
> mistaken?

You are not mistaken about mtimes.  However, you can tell tar to use
ctimes, and the operating system does not let you fudge ctimes.

> > here.  And if you're paranoid enough to want a cryptographic checksum,
> > you should use a better one than MD5; SHA1 say.
> 
> Is MD5 really that insecure?

That depends on how you measure security.  Let's put it this way:
better safe than sorry.  As far as I know, MD5 has not been cracked in
general, but there have been a bit of progress in cracking it, and
this is enough to convince me to not use it for new applications.



reply via email to

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