Message-ID: <B0FEA00E82A7D1118BFB00A0CC99027821320C@ARGON>
From: Michel de Ruiter <Michel AT smr DOT nl>
To: "'Eli Zaretskii'" <eliz AT is DOT elta DOT co DOT il>
Cc: "'DJGPP workers'" <djgpp-workers AT delorie DOT com>
Subject: RE: your mail
Date: Wed, 10 Mar 1999 14:21:26 +0100
X-Mailer: Internet Mail Service (5.5.2448.0)
Reply-To: djgpp-workers AT delorie DOT com

> > First, if `-n' is given explicitly, gzip should _not_ put a filename
> > in the gzipped file, whatever happens, e.g. so it could be 
> > used to get a really minimal filesize.
> Maybe, but this should be discussed further with the
> maintainers of GZip (and I'm not sure whether they exist
> anymore ;-).  The current behavior existed before I did
> the last port: `gzip' overrides -n on DOS if the name of
> the original file cannot be reproduced from the name of
> the compressed file because some of the characters are
> lost (like in the case you presented where file.ext ->
> file.egz loses the two last characters of the extension).

Hmm. So the behaviour of `-n' *should* depend on the
filename, the way it does now.

> Personally, I don't see anything wrong with that, and I wonder
> how 13 more bytes could be a significant change in the file's
> size.

It is more or a philosophical issue: when I say "no filename", I
expect "no filename".

> But anyway, I didn't change this behavior.

I didn't say that. :-)

> > Second, if gzip still does think it has strong reasons to put the
> > original filename in the gzipped file (because the filename gets
> > truncated or whatever), gunzip should also use that filename by
> > default (as if `-N' was used), to be consistent.
> Sorry, I don't see how this can be done.  `gzip' always by default
> records the original name, even on non-DOS systems (unless you say
> -n), and it always by default does NOT restore the original name,
> unless you say -N.  When `gunzip' sees the name, it cannot possibly
> know that it was recorded ``over the dead body'' of somebody who
> did say -n on DOS.  So it has no way of knowing whether to restore
> the original name or not.

I don't know whether it should be implemented this way. Best would
be, IMHO, to obey `-n'. Else, the following could be considered: if
`-n' is used but the filename is still recorded, the timestamp of
the file is not.

It is really not too important to me, but I found the current
behaviour very counter-intuitive. I spent some time until I
discovered `-n' was not obeyed on certain filenames.

I just thought I should report this bug, but now I see it is meant
as a feature...

Groente, Michel.