On Thursday, March 13, 2014 17:19:10 Paul Eggert wrote:
> Pavel Raiskup wrote:
> > Do you feel the patch is acceptable, you feel (or just plan
> > to) prepare some patch or possibly - should I fix something
> > in the patch?
>
> I'd like to see Sergey's opinion.
I wanted to say the same :). Serg
Pavel Raiskup wrote:
Do you feel the patch is acceptable, you feel (or just plan
to) prepare some patch or possibly - should I fix something
in the patch?
I'd like to see Sergey's opinion.
On Thursday, March 13, 2014 13:56:25 Paul Eggert wrote:
> Thanks, you've convinced me
I would be proud to see something like the proposed patch
pushed upstream then. At least bugreports relevant to this
incorrect use will never occur again.
Do you feel the patch is acceptable, you feel (or just
When dumping a file which is being actively updated by an application
(in our case it was an outlook pst file on our samba server), safe_read()
can sometimes return 0.
When it happens, sparse_dump_region() goes into an infinite loop.
I don't know what the proper fix would be. I just fixed it on
Pavel Raiskup schrieb:
Marcus, you are still able to 'cat | tar -x -f -'. I also don't think that
'tar -x' differs from 'tar -x -f -' because the '-f -' is just an
'./configure' time default which may differ from setup to setup (yes, yes,
the default seems to be always '-f -', though). BTW, fro
On 03/13/2014 01:32 PM, Pavel Raiskup wrote:
But I would like to convince you once more, Paul.
Thanks, you've convinced me that your original idea is better and that
we don't need to go the xargs route. The difference is that tar input
is binary, typically, and it'd be pretty rare for someon
Eric Blake:
> On 03/13/2014 12:00 PM, Paul Eggert wrote:
> > On 03/13/2014 10:32 AM, Pavel Raiskup wrote:
> >> Strictly
> >> speaking, GNU Coding Guidelines are talking about program_output_
> >
> > You're right, and I hadn't noticed that. How about doing things the way
> > xargs does them, as Er
On 03/13/2014 12:00 PM, Paul Eggert wrote:
> On 03/13/2014 10:32 AM, Pavel Raiskup wrote:
>> Strictly
>> speaking, GNU Coding Guidelines are talking about program_output_
>
> You're right, and I hadn't noticed that. How about doing things the way
> xargs does them, as Eric Blake pointed out? Tha
Hi Paul,
Hi Pavel,
Paul Eggert wrote
On 03/13/2014 10:32 AM, Pavel Raiskup wrote:
Strictly
speaking, GNU Coding Guidelines are talking about program_output_
You're right, and I hadn't noticed that. How about doing things the
way xargs does them, as Eric Blake pointed out? That seems like a
On 03/13/2014 10:32 AM, Pavel Raiskup wrote:
Strictly
speaking, GNU Coding Guidelines are talking about program_output_
You're right, and I hadn't noticed that. How about doing things the way
xargs does them, as Eric Blake pointed out? That seems like a nice
compromise.
On 03/13/2014 10:35 AM, Paul Eggert wrote:
> On 03/13/2014 01:21 AM, Pavel Raiskup wrote:
>>> We could detect that archive contents are coming from terminal input and
>>> fail immediately (IIRC tar waits indefinitely ATM until it's input is
>>> cut
>>> by ctrl+d or it is killed).
>> I meant somethi
On Thursday, March 13, 2014 09:35:26 Paul Eggert wrote:
> On 03/13/2014 01:21 AM, Pavel Raiskup wrote:
> >> We could detect that archive contents are coming from terminal input and
> >> fail immediately (IIRC tar waits indefinitely ATM until it's input is cut
> >> by ctrl+d or it is killed).
> > I
this compiles gnu tar 1.27.1 without complaint for me:
env CC='gcc -Dstrtoimax=strtoll -Dstrtoumax=strtoull' ./configure; gmake
thank you!
On 03/13/2014 01:21 AM, Pavel Raiskup wrote:
We could detect that archive contents are coming from terminal input and
fail immediately (IIRC tar waits indefinitely ATM until it's input is cut
by ctrl+d or it is killed).
I meant something like the patch attached, could you please consider?
I tri
On Thursday, March 13, 2014 09:21:44 Pavel Raiskup wrote:
> > We could detect that archive contents are coming from terminal input and
> > fail immediately (IIRC tar waits indefinitely ATM until it's input is cut
> > by ctrl+d or it is killed).
>
> I meant something like the patch attached, could
Pavel Raiskup wrote:
We could detect that archive contents are coming from terminal input and
fail immediately (IIRC tar waits indefinitely ATM until it's input is cut
by ctrl+d or it is killed).
I think this may be a good idea. It is a common feature among the
compressors used by tar:
$ l
> We could detect that archive contents are coming from terminal input and
> fail immediately (IIRC tar waits indefinitely ATM until it's input is cut
> by ctrl+d or it is killed).
I meant something like the patch attached, could you please consider?
I tried to write testcase for this and I faile
17 matches
Mail list logo
