Discussion:
Info-Zip & EA's
(too old to reply)
LSoens
2018-03-17 15:46:09 UTC
Permalink
AFAIK Info-Zip's zip.exe normally preserves Extended attributes when
updating an archive, but obviously not everything, here: ".SUBJECT"
EA. Is there an option to zip.exe which forces to preserve this one?
Yeah, but a workaround "SysGetEA&SysPutEA" wouldn't be that elegant
:-)

Thanks, Lothar
--
lothar .dot. soens .at. t .minus. online .dot. de

Wegen Unregelmäßigkeiten im Betrieb fährt die Bahn heute pünktlich.
Due to irregular service all trains go on schedule today.
Dave Yeo
2018-03-17 17:07:03 UTC
Permalink
Post by LSoens
AFAIK Info-Zip's zip.exe normally preserves Extended attributes when
updating an archive, but obviously not everything, here: ".SUBJECT"
EA. Is there an option to zip.exe which forces to preserve this one?
Yeah, but a workaround "SysGetEA&SysPutEA" wouldn't be that elegant
:-)
Thanks, Lothar
Which version of zip? I believe there is a bug in the one distributed
with RPM/YUM related to EAs with a fixed one in the experimental repo.
Dave
LSoens
2018-03-17 18:21:05 UTC
Permalink
Until now I'm testing with Paul S.' ports v.3.00 & v.2.31 only.

But possibly not a "bug". I found the following in Linux' "man zip"
below the "-X" option (which is the opposite, but...)
<quote>
The zip format uses extra
fields to include additional information for each entry. Some
extra fields are specific to particular systems while others are
applicable to all systems. Normally when zip reads entries from
an existing archive, it reads the extra fields it knows, strips
the rest, and adds the extra fields applicable to that system.
</quote>
So I suspect that OS/2's ".SUBJECT" is not "normal" for Info-Zip?

Next: is it, _in practice_, really desirable to have this EA preserved
from update to update?
Unless there is a very simple option, I feel it useless to build a
workaround that nobody needs...

Thanks, Lothar
Post by Dave Yeo
Post by LSoens
AFAIK Info-Zip's zip.exe normally preserves Extended attributes when
updating an archive, but obviously not everything, here: ".SUBJECT"
EA. Is there an option to zip.exe which forces to preserve this one?
Yeah, but a workaround "SysGetEA&SysPutEA" wouldn't be that elegant
:-)
Thanks, Lothar
Which version of zip? I believe there is a bug in the one distributed
with RPM/YUM related to EAs with a fixed one in the experimental repo.
Dave
--
lothar .dot. soens .at. t .minus. online .dot. de

Wegen Unregelmäßigkeiten im Betrieb fährt die Bahn heute pünktlich.
Due to irregular service all trains go on schedule today.
Dave Yeo
2018-03-18 02:30:17 UTC
Permalink
Post by LSoens
Until now I'm testing with Paul S.' ports v.3.00 & v.2.31 only.
But possibly not a "bug". I found the following in Linux' "man zip"
below the "-X" option (which is the opposite, but...)
<quote>
The zip format uses extra
fields to include additional information for each entry. Some
extra fields are specific to particular systems while others are
applicable to all systems. Normally when zip reads entries from
an existing archive, it reads the extra fields it knows, strips
the rest, and adds the extra fields applicable to that system.
</quote>
So I suspect that OS/2's ".SUBJECT" is not "normal" for Info-Zip?
Next: is it, _in practice_, really desirable to have this EA preserved
from update to update?
Unless there is a very simple option, I feel it useless to build a
workaround that nobody needs...
OK, I just tested with the RPM installed zip (v3 from info-zip), subject
EAs are preserved so I guess a bug with Paul's builds. In my testcase,
an old file downloaded by Mozilla (probably SeaMonkey) which until
recently (at some point, perhaps FF24, it broke) saved the URL that the
file originated from in the Subject EA along with the original name and
date in the Comments EA. Personally I like this info to be preserved,
especially the URL, as that is easily forgotten. Some versions of wget
also preserved this info, perhaps in a different EA.
Dave
LSoens
2018-03-18 18:28:22 UTC
Permalink
Just tested with that zip.exe (of Feb 2018): The ".subject" EA is
_not_ preserved when updating an archive (e.g. adding 1 file). Nor
didn't Paul's ever. IMHO not to blame as a "bug" , as the ports just
take (nearly?) "all features 1:1" from info-zip, I suppose. Together
with the "-S" problem obviously fixed :-)
Never mind. Thanks very much for your suggestion. So I will re-arrange
a few Lego bricks in my little tool :-)

Regards, Lothar
Post by Dave Yeo
OK, I just tested with the RPM installed zip (v3 from info-zip), subject
EAs are preserved so I guess a bug with Paul's builds. In my testcase,
an old file downloaded by Mozilla (probably SeaMonkey) which until
recently (at some point, perhaps FF24, it broke) saved the URL that the
file originated from in the Subject EA along with the original name and
date in the Comments EA. Personally I like this info to be preserved,
especially the URL, as that is easily forgotten. Some versions of wget
also preserved this info, perhaps in a different EA.
--
lothar .dot. soens .at. t .minus. online .dot. de

Wegen Unregelmäßigkeiten im Betrieb fährt die Bahn heute pünktlich.
Due to irregular service all trains go on schedule today.
LSoens
2018-03-19 08:36:43 UTC
Permalink
Exactly I like such information coming with the downloaded archive.

My question: should a zip update (i.e. contents modification) preserve
the EA or not, "our" zip.exe obviously doesn't and I've only found in
the docs about EAs what I'd quoted before.
Option 1: a workaround with SysGetEA&SysPutEA in my little tool
Option 2: leave it "as designed", feature not "bug".

This morning ;-), I personally prefer to leave it as-is. For I may
consider the .subject EA as kind of unique "label" on this certain
archive _file_, but not as part of its contents. And still up to me to
add another EA to my (new or same) modified file or not...
Most important anyway: zip.exe conserves the EAs of files _inside_ the
archive, ok.

Thanks again for all feedback.
Regards, Lothar
file downloaded ... saved the URL that the
file originated from in the Subject EA along with the original name and
date in the Comments EA. Personally I like this info to be preserved,
especially the URL, as that is easily forgotten.
--
lothar .dot. soens .at. t .minus. online .dot. de

Wegen Unregelmäßigkeiten im Betrieb fährt die Bahn heute pünktlich.
Due to irregular service all trains go on schedule today.
edit to send email
2018-03-21 22:00:44 UTC
Permalink
In <INZNCBOtXuBC-pn2-***@panda2>, on 03/19/18
at 08:36 AM, "LSoens" <***@nospam.invalid> said:

This whole thread has been copied to the OS2Voice news list (the admin
address) of which I am admin.

Every message in the news has these lines added:
=== NewsGate v1.0 gamma 2
# Origin: News Gate @ Net396 -Huntsville, AL - USA (1:396/4)

Since I haven't had a FIDO address for about 15 years I don't know how to
contact the sysadmin. Does anyone here know?
Post by LSoens
Exactly I like such information coming with the downloaded archive.
My question: should a zip update (i.e. contents modification) preserve
the EA or not, "our" zip.exe obviously doesn't and I've only found in
the docs about EAs what I'd quoted before.
Option 1: a workaround with SysGetEA&SysPutEA in my little tool Option
2: leave it "as designed", feature not "bug".
This morning ;-), I personally prefer to leave it as-is. For I may
consider the .subject EA as kind of unique "label" on this certain
archive _file_, but not as part of its contents. And still up to me to
add another EA to my (new or same) modified file or not... Most important
anyway: zip.exe conserves the EAs of files _inside_ the archive, ok.
Thanks again for all feedback.
Regards, Lothar
file downloaded ... saved the URL that the
file originated from in the Subject EA along with the original name and
date in the Comments EA. Personally I like this info to be preserved,
especially the URL, as that is easily forgotten.
Cheers, Bjorn.
--
-----------------------------------------------------------
***@guzzi.demon.nl (Bjorn Rietdijk)
-----------------------------------------------------------
Andreas Kohl
2018-03-19 00:33:53 UTC
Permalink
Post by LSoens
Until now I'm testing with Paul S.' ports v.3.00 & v.2.31 only.
But possibly not a "bug". I found the following in Linux' "man zip"
below the "-X" option (which is the opposite, but...)
<quote>
The zip format uses extra
fields to include additional information for each entry. Some
extra fields are specific to particular systems while others are
applicable to all systems. Normally when zip reads entries from
an existing archive, it reads the extra fields it knows, strips
the rest, and adds the extra fields applicable to that system.
</quote>
So I suspect that OS/2's ".SUBJECT" is not "normal" for Info-Zip?
I don't know about the changes in different inofficial private builds of
InfoZip's zip. zip's behaviour under Linux depends on architecture and
file systems. The quoted man page seems to be outdated. I would
recommend to use simply the documentation from the official release:
<ftp://ftp.infozip.org/pub/infozip/os2/zip300c.zip>
All EAs are usually archived but it depends on the extraction utility
implementation and the target file system how they can be unarchived.

--
Andreas
Doug Bissett
2018-03-18 02:00:50 UTC
Permalink
Post by Dave Yeo
Post by LSoens
AFAIK Info-Zip's zip.exe normally preserves Extended attributes when
updating an archive, but obviously not everything, here: ".SUBJECT"
EA. Is there an option to zip.exe which forces to preserve this one?
Yeah, but a workaround "SysGetEA&SysPutEA" wouldn't be that elegant
:-)
Thanks, Lothar
Which version of zip? I believe there is a bug in the one distributed
with RPM/YUM related to EAs with a fixed one in the experimental repo.
Dave
It was not for EAs, it was for hidden, and system files (the "-S"
parameter wasn't working). The fixed version is now in the netlabs-rel
repo.

Don't know about ".Subject" though.
--
From Doug Bissett's ArcaOS
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)
Loading...