Thanks.
This a bug. When I execute tar without --listed-incremental
$path$snar.snar (as the only change) these error messages do not
appear.
Also, of course the directory exists and the type of it is a directory.
I also tried --absolute-names, but this was not the reason.
Do you agree that it is
Paul Eggert wrote:
POSIX says that short reads are allowed only near end-of-file,
or when signals arrive, or for pipes, FIFOs, and special files.
They are not allowed while reading in the middle of a regular file,
Weren't GNU programs supposed to be free from such limitations[1]? For
example
On 2011-09-27, at 12:28 PM, Sergey Poznyakoff wrote:
Kevin Fox kevin@pnnl.gov ha escrit:
What about SIGSTOP/SIGCONT? I don't believe they can avoid those.
SIGSTOP cannot be caught, blocked, or ignored. It is used only by
debuggers.
Isn't it also used by Ctrl-Z in bash, and then bg/fg
On Sep 27, 2011, at 11:35 AM, Andreas Dilger wrote:
SIGSTOP cannot be caught, blocked, or ignored. It is used only by
debuggers.
Isn't it also used by Ctrl-Z in bash, and then bg/fg will send
SIGCONT when it resumes.
Cntl-Z causes the shell to send SIGTSTP, not SIGSTOP.
I'm on the side
On Tue, 2011-09-27 at 11:35 -0700, Andreas Dilger wrote:
On 2011-09-27, at 12:28 PM, Sergey Poznyakoff wrote:
Kevin Fox kevin@pnnl.gov ha escrit:
What about SIGSTOP/SIGCONT? I don't believe they can avoid those.
SIGSTOP cannot be caught, blocked, or ignored. It is used only by
Antonio Diaz Diaz ant_d...@teleline.es ha escrit:
Weren't GNU programs supposed to be free from such limitations[1]?
Yes, as I've already said that shouldn't be difficult to do. That
does not imply, however, that filesystem writers should ignore POSIX
standard if they want their FS to be
Kevin Fox kevin@pnnl.gov ha escrit:
It can use SIGTSTP/SIGCONT instead, but to the same effect I think.
There are a few other ones a terminal can issue too like SIGTTIN and
SIGTTOU.
Each signal has its own purpose. Delivering SIGTTIN where there is
no tty input for background process
On Tue, 2011-09-27 at 11:58 -0700, Sergey Poznyakoff wrote:
Kevin Fox kevin@pnnl.gov ha escrit:
It can use SIGTSTP/SIGCONT instead, but to the same effect I think.
There are a few other ones a terminal can issue too like SIGTTIN and
SIGTTOU.
Each signal has its own purpose.
Kevin Fox kevin@pnnl.gov ha escrit:
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;
On 09/27/11 12:18, Kevin Fox wrote:
No, what could happen is a user could stop tar mid stream, then continue
it, and a read might show up partial and tar would freak out.
In practice real systems don't do partial reads after a start/continue,
when you're reading such small buffers from regular
On Tue, 2011-09-27 at 12:48 -0700, Sergey Poznyakoff wrote:
Kevin Fox kevin@pnnl.gov ha escrit:
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 =
Paul Eggert egg...@cs.ucla.edu ha escrit:
Would it make sense to install the following patch to GNU tar?
Yes, that looks nice.
Regards,
Sergey
Kevin Fox kevin@pnnl.gov ha escrit:
Case two:
If a read() is interrupted by a signal after it has successfully read
some data, it shall return the number of bytes read.
safe_rw only handles the former, not the latter case, which is what I am
talking about.
Yes, you're right. Thanks
On 2011-09-27, at 1:48 PM, Sergey Poznyakoff wrote:
Kevin Fox kevin@pnnl.gov ha escrit:
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,
On Tue, 2011-09-27 at 13:37 -0700, Paul Eggert wrote:
On 09/27/11 13:35, Kevin Fox wrote:
As far as I can figure, partial read is an integral part of the read
api. You can't disable enough stuff so that it doesn't ever happen.
The SA_RESTART fix isn't intended to work around the
On 2011-09-27, at 2:38 PM, Andreas Dilger wrote:
On 2011-09-27, at 1:48 PM, Sergey Poznyakoff wrote:
Kevin Fox kevin@pnnl.gov ha escrit:
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 (;;)
On Tue, 2011-09-27 at 13:48 -0700, Paul Eggert wrote:
On 09/27/11 13:40, Kevin Fox wrote:
you don't
need that patch at all since the code already handles that case, without
the patch
I'm not worried about that 'read' call. I'm worried about the
dozens or hundreds of other system calls
17 matches
Mail list logo
