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.

LSoens wrote:
> 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

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

On Sat, 17 Mar 2018 17:07:03 UTC, Dave Yeo <dave.r.yeo@gmail.com>
wrote:

> LSoens wrote:
> > 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.

On Sat, 17 Mar 2018 17:07:03 UTC, Dave Yeo <dave.r.yeo@gmail.com>
wrote:

> LSoens wrote:
> > 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)

LSoens wrote:
> 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

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

On Sun, 18 Mar 2018 02:30:17 UTC, Dave Yeo <dave.r.yeo@gmail.com>
wrote:

> 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 schrieb:
> 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

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

On Sun, 18 Mar 2018 02:30:17 UTC, Dave Yeo <dave.r.yeo@gmail.com>
wrote:

> 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.

In <INZNCBOtXuBC-pn2-dU4une11MGut@panda2>, on 03/19/18
at 08:36 AM, "LSoens" <nomail@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?

>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

>On Sun, 18 Mar 2018 02:30:17 UTC, Dave Yeo <dave.r.yeo@gmail.com> wrote:

>> 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.
--
-----------------------------------------------------------
bjorn.rietdijk@guzzi.demon.nl (Bjorn Rietdijk)
-----------------------------------------------------------