[Top][All Lists]

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

Re: [Bug-tar] Tar cheats when directed to /dev/null

From: Eric Blake
Subject: Re: [Bug-tar] Tar cheats when directed to /dev/null
Date: Thu, 25 Mar 2010 15:12:34 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100301 Fedora/3.0.3-1.fc12 Lightning/1.0b1 Thunderbird/3.0.3

On 03/25/2010 12:51 PM, Phillip Susi wrote:
> Depending on broken behavior is itself, broken behavior.  Every other
> unix utility writes its output to /dev/null when asked to.

POSIX requires that /dev/null is an infinite data sink.  POSIX also
requires the as-if rule - an implementation is free to use alternate
implementations, provided that they behave as if they meet the standards
such that a confirming application cannot spot the difference.  Short of
strace (which is outside the scope of POSIX), you cannot tell whether
tar wrote to /dev/null or optimized for speed by avoiding what would be
a wasted write().  Either way, the data still goes to an infinite sink.
 I see no violation of POSIX in this behavior, therefore I contend that
tar is NOT relying on broken behavior.

>  Tar should
> do so when asked as well, rather than silently ignore your instructions
> and fundamentally alter its behavior.  At the very least it should print
> a warning informing you that it has decided to ignore your instructions
> and not do as you asked.

POSIX does not permit spurious warnings - an application that writes to
stderr must be doing so to report an error, and must exit with non-zero
status, unless it was one of the applications given a special exception
to use stderr for other purposes.  And what good would a warning do
anyways?  By the as-if rule, tar obeyed your request to send data to the
infinite data sink - it does not matter whether it bypassed the write()
in doing so, so there is nothing to warn about.

> What's next?  rm deciding that you didn't REALLY mean to delete that
> file and just pretending it succeeded?  Sheesh!

No, because that would be a difference that could be observed by a
compliant app.

Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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