gzip theologians,
Just for information, up to now, pigz would merrily unlink the hard link of the
input file, even if it has other hard links. While I’m not sure I understand
why it shouldn’t do that (that is in fact what you asked it to do), in the
spirit of behaving mostly like gzip, it will
Dnia niedziela, 22 sierpnia 2021 13:21:45 CEST Adler, Mark pisze:
> Just for information, up to now, pigz would merrily unlink the hard link of
> the input file, even if it has other hard links. While I’m not sure I
> understand why it shouldn’t do that (that is in fact what you asked it to
> do),
Dnia sobota, 21 sierpnia 2021 15:55:45 CEST Jim Meyering pisze:
> I.e., we have to weigh "what could go wrong?" against "what would be
> improved?" In this case, the weights are small on each side. That alone
> argues against making a semantics-changing modification to such a tool.
The bad weight
On Fri, Aug 20, 2021 at 5:16 PM Paul Eggert wrote:
> On 8/20/21 7:52 AM, Krzysztof Żelechowski wrote:
>
> >> echo hello >a
> >> ln a b
> >> gzip -k b && gzip -cd b.gz >>b
> >>
> >> This would trash 'a' if gzip -k succeeded. (Same with 'ln -s'.)
> >
> > The appending redirection operator has nothin
Dnia piątek, 20 sierpnia 2021 17:15:43 CEST Paul Eggert pisze:
> On 8/20/21 7:52 AM, Krzysztof Żelechowski wrote:
> >> echo hello >a
> >> ln a b
> >> gzip -k b && gzip -cd b.gz >>b
> >>
> >> This would trash 'a' if gzip -k succeeded. (Same with 'ln -s'.)
> >
> > The appending redirection operator
On 8/20/21 7:52 AM, Krzysztof Żelechowski wrote:
echo hello >a
ln a b
gzip -k b && gzip -cd b.gz >>b
This would trash 'a' if gzip -k succeeded. (Same with 'ln -s'.)
The appending redirection operator has nothing to do with gzip.
That's true even without -k: if plain 'gzip b' succeeded in th
Dnia piątek, 20 sierpnia 2021 16:42:54 CEST Paul Eggert pisze:
> On 8/20/21 5:20 AM, Krzysztof Żelechowski wrote:
> >> gzip -k b && gzip -cd b.gz >b
> >>
> >> which would trash the hard-linked file as well.
> >
> > That would replace the content of the file b with the content of the file
> > b. H
On 8/20/21 5:20 AM, Krzysztof Żelechowski wrote:
gzip -k b && gzip -cd b.gz >b
which would trash the hard-linked file as well.
That would replace the content of the file b with the content of the file b.
How bad can that be? ;-)
It could be a problem as-is if some other file reads 'a' in the
Dnia czwartek, 19 sierpnia 2021 23:32:44 CEST Paul Eggert pisze:
> On 8/19/21 1:43 PM, Krzysztof Żelechowski wrote:
> > The command { gzip b; } fails because it would compress [a] without
> > renaming it.
> > The command { gzip -k b; } would not compress [a], so there is no reason
> > to
> > fail.
Dnia czwartek, 19 sierpnia 2021 23:32:44 CEST Paul Eggert pisze:
> On 8/19/21 1:43 PM, Krzysztof Żelechowski wrote:
> > The command { gzip b; } fails because it would compress [a] without
> > renaming it.
> > The command { gzip -k b; } would not compress [a], so there is no reason
> > to
> > fail.
On 8/19/21 1:43 PM, Krzysztof Żelechowski wrote:
The command { gzip b; } fails because it would compress [a] without renaming
it.
The command { gzip -k b; } would not compress [a], so there is no reason to
fail.
There is a safety reason to fail. A naive user might do this:
gzip -k b && gzip -c
Dnia czwartek, 19 sierpnia 2021 17:28:51 CEST Rodrigo Campos pisze:
> On 8/19/21 3:50 PM, Antonio Diaz Diaz wrote:
> > Rodrigo Campos wrote:
> > $ touch a && ln a b && ls -go *
> > -rw-r--r-- 2 0 Aug 19 15:29 a
> > -rw-r--r-- 2 0 Aug 19 15:29 b
> > $ gzip -k b
> > gzip: b has 1 other link -- uncha
On 8/19/21 3:50 PM, Antonio Diaz Diaz wrote:
Rodrigo Campos wrote:
{ >>a && ln a b && gzip -k b
}
Exactly, the original file is unaffected, therefore nothing to fix in
this specific patch. Note the same happens without "-k" too.
I think the point of Krzysztof is that the patch is incomplete
Rodrigo Campos wrote:
{ >>a && ln a b && gzip -k b
}
Exactly, the original file is unaffected, therefore nothing to fix in
this specific patch. Note the same happens without "-k" too.
I think the point of Krzysztof is that the patch is incomplete because, in
addition to keep the original fil
On 8/19/21 2:29 AM, Krzysztof Żelechowski wrote:
The patch just makes sure the original files are
unchanged, as the topic says, and that is working as far as I understand.
It is >
Also, can you please provide specific steps to reproduce?
{ >>a && ln a b && gzip -k b
}
Exactly, the origi
Dnia czwartek, 19 sierpnia 2021 00:43:26 CEST Rodrigo Campos pisze:
> On 8/17/21 7:43 PM, Krzysztof Żelechowski wrote:
> > Dnia sobota, 9 lutego 2013 16:21:13 CEST Rodrigo Campos pisze:
> >> Hi,
> >>
> >> Please keep me in Cc: since I'm not subscribed.
> >>
> >> This path just adds the "--keep" o
On 8/17/21 7:43 PM, Krzysztof Żelechowski wrote:
Dnia sobota, 9 lutego 2013 16:21:13 CEST Rodrigo Campos pisze:
Hi,
Please keep me in Cc: since I'm not subscribed.
This path just adds the "--keep" option to keep original files unchanged.
The patch is very simple and I have tried it here (manpa
Dnia sobota, 9 lutego 2013 16:21:13 CEST Rodrigo Campos pisze:
> Hi,
>
> Please keep me in Cc: since I'm not subscribed.
>
> This path just adds the "--keep" option to keep original files unchanged.
> The patch is very simple and I have tried it here (manpage and binary) and
> it seems to work ju
18 matches
Mail list logo
