bug-tar
[Top][All Lists]
Advanced

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

Re: [Bug-tar] [patch v3] Bug / question in tar


From: Joerg Schilling
Subject: Re: [Bug-tar] [patch v3] Bug / question in tar
Date: Sun, 30 Mar 2014 13:36:04 +0200
User-agent: nail 11.22 3/20/05

Paul Eggert <address@hidden> wrote:

> Tim Kientzle wrote:
> > If you really believe that sending output to /dev/null should not do 
> > anything, make it a fatal error so people won't rely on it.
>
> That would be silly, as it defeats the whole point of having a /dev/null 
> for output.
>
> At this point we're arguing only about theory, since GNU tar actually 
> does read the files in this case.  But in other cases, programs avoid 

It seems that you are mistaken. Gtar does not read the files in this case:

gtar cf /dev/null /usr
gtar: Entferne führende ?/? von Elementnamen
gtar: Entferne führende ?/? von Zielen harter Verknüpfungen
49.358r 2.940u 7.180s 20% 0M 0+0k 0st 0+0io 0pf+0w

star cf /dev/null /usr
star: 763471 blocks + 0 bytes (total of 7817943040 bytes = 7634710.00k).
9:38.746r 4.470u 48.610s 9% 0M 0+0k 0st 0+0io 0pf+0w

It is unlikely that gtar is nearly 12x more efficient than star.

But let us check star in size estimation mode that does not read files:

star c -nullout /usr  
star: 763471 blocks + 0 bytes (total of 7817943040 bytes = 7634710.00k).
40.308r 1.080u 6.070s 17% 0M 0+0k 0st 0+0io 0pf+0w

And as this is on Solaris, we have /dev/zero, so let us check gtar to /dev/zero:

gtar cf /dev/zero /usr
gtar: Entferne führende ?/? von Elementnamen
gtar: Entferne führende ?/? von Zielen harter Verknüpfungen
10:06.437r 8.300u 48.370s 9% 0M 0+0k 0st 0+0io 0pf+0w


> input as an optimization, and that's perfectly all right.  For example, 
> 'diff FOO FOO' doesn't read FOO twice, and there's nothing wrong with 

While diff may get it's result without knowing how this works, tar is known to 
read the files.

>
> It sounds like enough people are misusing GNU tar in the way you 
> describe that, if we improved its performance in this case, we'd need to 
> add a --be-stupid option so that tar would continue to read data that it 
> doesn't need to.  (Perhaps you could come up with a better name for the 
> option.  :-)

Tar reads the files in such a case, it is gtar that behaves different from 
other tar implementations.

BTW: The '?' chars in the output from gtar let me asume a bug. I cannot believe 
this was intentionally.

Jörg

-- 
 EMail:address@hidden (home) Jörg Schilling D-13353 Berlin
       address@hidden                (uni)  
       address@hidden (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily



reply via email to

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