extra bytes in zip archive when used with logrotate

[shimi]

On Mon, Aug 6, 2012 at 7:16 PM, Oleg Goldshmidt <pub at goldshmidt.org> wrote:

> shimi <linux-il at shimi.net> writes:
>
> > On Mon, Aug 6, 2012 at 5:35 PM, Oleg Goldshmidt <pub at goldshmidt.org>
> wrote:
> >
> >                $ unzip -l file.log.zip
> >      Archive:  file.log.zip
> >      warning [file.log.zip]:  16 extra bytes at beginning or within
> >      zipfile
> >        (attempting to process anyway)
> >        Length      Date    Time    Name
> >      ---------  ---------- -----   ----
> >          71992  08-06-2012 16:05   zipit.10182
> >      ---------                     -------
> >          71992                     1 file
> >
> >      and the archive cannot be opened:
> >
> > Maybe I missed it, but, what _are_ the first 16 bytes? Anything
> > interesting? It sounds like something is sent to the zip that is not
> > supposed to be sent there, e.g. redirect from stderr, like a notice
> > going there. Any chance those 16 bytes are human readable ASCII?
>
> Hmm... It never occurred to me to check because the warning does not
> say that the extra bytes are at the beginning - it says "at beginning
> or within". This seems to be consistent with the unzip code that
> outputs the warning when some combination of offsets does not look
> right (maybe I missed something but it didnt look like the beginning
> of the file was specificlly checked).
>
> I will only regain access to the test system on Wednesday - will od or
> similar then.
>
>
Good point. Though if my direction is true, good chances are that it will
be in the beginning or the end, no? I guess 'strings' can be used, too :-)

Actually, thinking it further, ZIP's directory ('filesystem'), AFAIK, is at
the end of the file, and you get the error even with listing only. Maybe
gibberish went to the end :-)

-- Shimi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20120806/fb839c39/attachment.html>