Re: CygUtils Version of zip (and Symlinks)

[Cosmin Truta <cosmin at cs dot toronto dot edu>]

Hi,
Sorry for not being able to answer earlier.

On Tue, 23 May 2000, Charles Wilson wrote:

> > > > The files produced have the HostOS value equal to 11 (WinNT filesystem),
> > > > not 3 (Unix), and the NTSD descriptors are also stored in the zip archive,
> > > > along with the universal time (as in the Unix versions).
> > 
> > This sounded like a good thing (especially with the ntsec stuff which
> > uses NTSD descriptors) so the current versions (zip-2.3, unzip-5.41) on
> > CygUtils are built using win32/makefile.gcc.
> > 
> > I did not look too closely at the code; perhaps the symlink handling
> > stuff that is there for Unix platforms, gets #ifdef'd out in this
> > configuration? If so, it shouldn't be too hard to locate that section
> > and #ifdef it back in for __CYGWIN__.
> > 
> 
> Hmmm...I've been thinking. I'm not sure you *want* to store NTSD
> descriptors in a zip file. Suppose I have SID 1-3661234856-525, and zip
> up my files, and give the zip to you. Then, you unzip the file but there
> is no user #525 on your machine. What happens?

You can read the details in proginfo/nt.sd which is present in both zip
and unzip packages. Here is an excerpt:

"When creating .zip files with security which are intended for transport
across systems, it is important to take into account the relevance of
access control entries and the associated Sid of each entry.  For example,
if a .zip file is created on a Windows NT workstation, and file security
references local workstation user accounts (like an account named Fred),
this access entry will not be relevant if the .zip file is transported to
another machine.  Where possible, take advantage of the built-in
well-known
groups, like Administrators, Everyone, Network, Guests, etc.  These groups
have the same meaning on any Windows NT machine.  Note that the names of 
these groups may differ depending on the language of the installed Windows
NT, but this isn't a problem since each name has well-known ID that, upon
restore, translates to the correct group name regardless of locale."

I didn't get involved with the NT SD devel stuff, so I don't know its
implementation in detail. You might wish to contact Info-ZIP at
<Zip-Bugs@lists.wku.edu>

Regarding the symlink: the cygwin/Win32 port of zip behaves exactly like
any other_compiler/Win32 platform so the Unix stuff gets #ifdef'd out.
If you want it, then you should recompile zip as cygwin/Unix. The patch is
provided by Chuck.

> When you get right down to it, cygwin is NOT windows. It does everything
> it can to make windows look like Unix, so that apps can run *as if they
> were on unix* with little or no changes. So, by that logic,
> cygwin-zip/unzip =should= be built as unix-ish apps, not windows-ish
> ones.

Maybe you are right.
I personally look at gcc as a free alternative for a good Win32 compiler,
but I agree that cygwin is a "Unix on Win" and maybe most of the people
look at it that way.

> p.s. cosmin: I don't know if you're subscribed to the cygwin list; for
> the context of this email, see the discussion thread: 
> http://sourceware.cygnus.com/ml/cygwin/2000-05/threads.html#00782

Thank you for letting me know. I didn't subscribe to the cygwin list but I
will look at this thread periodically.

	Cosmin


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com