bug-tar
[Top][All Lists]
Advanced

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

Re: [Bug-tar] Tar short read


From: Kevin Fox
Subject: Re: [Bug-tar] Tar short read
Date: Tue, 27 Sep 2011 12:02:04 -0700

On Tue, 2011-09-27 at 11:35 -0700, Sergey Poznyakoff wrote:
> Kevin Fox <address@hidden> ha escrit:
> 
> > I can't see any way that a program receiving a signal like SIGCONT
> > during a partial read and it not properly handling the partial read
> > response would not be considered a bug.
> 
> Tar handles that case and retries the read, *if* it is able to handle
> the delivered signal (see the safe_read function).  

Thats not how I read that function:
size_t safe_rw (int fd, void const *buf, size_t count)
{
  enum { BUGGY_READ_MAXIMUM = INT_MAX & ~8191 };
  for (;;)
    {
      ssize_t result = rw (fd, buf, count);
      if (0 <= result)
        return result;

short read, return right away without looping. I don't believe tar
handles it.

In fact, looking at the implementation of "safe_read", it looks like in
tru64 5.1, it will still break tar since it just shrinks count and tries
again and this would look like a partial return to tar. "safe_read"
behaves more like the read described in glibc then in posix read.

So, either safe_rw should be changed to follow the read semantics tar is
expecting of it, or tar should change to match the semantics of the
safe_rw library being used.

> SIGSTOP cannot be
> handled in principle.

Then you must assume its possible to get one, and is not possible to
block it, so therefore partial reads are expected by the posix spec?

> SIGCONT is normally sent only by debuggers.

Bash does too on fg. I believe other terminal related things do as well.

Thanks,
Kevin

> 
> Regards,
> Sergey





reply via email to

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