RE: CygUtils Version of zip (and Symlinks)

RE: CygUtils Version of zip (and Symlinks)

[Parker, Ron]

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

ISTM that the right behavior would be for cygwin to build a UNIX-ish (un)zip
and for mingw to build a Windows style program.  As already pointed out
cygwin should be thought of as "Unix on Win" and IMO mingw should be thought
of as "as a free alternative for a good Win32 compiler". 

I realize that cygwin and mingw are both supported by the same compiler, but
supplying -mno-cygwin causes gcc to switch from cygwin to mingw behavior and
__MINGW32__ becomes defined.

This may be more a question for cygwin-developers, but I hate crossposts and
know most readers of that list at least review this one.  So, wouldn't it be
appropriate when compiling without -mno-cygwin for the specs file to define
"unix", "UNIX" and similar "standard" defines?  They seem to be checked for
in newlib, zlib, X11, and many other sources?

Yes I know I can make this change in my local sources, but I prefer to work
with standard sources and now seemed a good time to bring it up.  I have
been wondering about it for some time.

Re: CygUtils Version of zip (and Symlinks)

[Chris Faylor]

On Thu, May 25, 2000 at 12:05:53PM -0400, Chris Faylor wrote:
>On Thu, May 25, 2000 at 10:56:53AM -0500, Parker, Ron wrote:
>>This may be more a question for cygwin-developers, but I hate crossposts and
>>know most readers of that list at least review this one.  So, wouldn't it be
>>appropriate when compiling without -mno-cygwin for the specs file to define
>>"unix", "UNIX" and similar "standard" defines?  They seem to be checked for
>>in newlib, zlib, X11, and many other sources?
>
>I don't see why it would be appropriate to define UNIX when you're specifying
>a command line option that says "This is not UNIX".  So, no, I don't believe
>that this is appropriate.  I don't even know that newlib will build correctly
>with -mno-cygwin.

Sorry.  I misread what was written above.  It does make sense to define these
and, in fact, I am fairly certain that they used to be defined.

Apologies for the misinterpretation.

cgf

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

RE: CygUtils Version of zip (and Symlinks)

[Earnie Boyd]

--- "Parker, Ron" <rdparker@butlermfg.com> wrote:
> > > 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.
> 
> ISTM that the right behavior would be for cygwin to build a UNIX-ish (un)zip
> and for mingw to build a Windows style program.  As already pointed out
> cygwin should be thought of as "Unix on Win" and IMO mingw should be thought
> of as "as a free alternative for a good Win32 compiler". 
> 

I agree.

> I realize that cygwin and mingw are both supported by the same compiler, but
> supplying -mno-cygwin causes gcc to switch from cygwin to mingw behavior and
> __MINGW32__ becomes defined.
> 

This is really a pseudo cross-compile and would be better handled IMO as a true
canadian-cross so that the headers and support libs aren't in the same
directory.

> This may be more a question for cygwin-developers, but I hate crossposts and
> know most readers of that list at least review this one.  So, wouldn't it be
> appropriate when compiling without -mno-cygwin for the specs file to define
> "unix", "UNIX" and similar "standard" defines?  They seem to be checked for
> in newlib, zlib, X11, and many other sources?
> 

Well actually, I've wondered about adding unix and linux and 'similar
"standard" defines' myself.  What would you consider "standard"?

> Yes I know I can make this change in my local sources, but I prefer to work
> with standard sources and now seemed a good time to bring it up.  I have
> been wondering about it for some time.

I have modified my specs file to remove the defines for _WIN32 and WINNT.  I've
thought of adding unix type defines but haven't yet.

Regards,

=====
---
   Earnie Boyd: < mailto:earnie_boyd@yahoo.com >
            __Cygwin: POSIX on Windows__
Cygwin Newbies: < http://www.freeyellow.com/members5/gw32/index.html >
           __Minimalist GNU for Windows__
  Mingw32 List: < http://www.egroups.com/group/mingw32/ >
    Mingw Home: < http://www.mingw.org/ >

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/

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

Re: CygUtils Version of zip (and Symlinks)

[Chris Faylor]

On Thu, May 25, 2000 at 10:56:53AM -0500, Parker, Ron wrote:
>This may be more a question for cygwin-developers, but I hate crossposts and
>know most readers of that list at least review this one.  So, wouldn't it be
>appropriate when compiling without -mno-cygwin for the specs file to define
>"unix", "UNIX" and similar "standard" defines?  They seem to be checked for
>in newlib, zlib, X11, and many other sources?

I don't see why it would be appropriate to define UNIX when you're specifying
a command line option that says "This is not UNIX".  So, no, I don't believe
that this is appropriate.  I don't even know that newlib will build correctly
with -mno-cygwin.

cgf

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

Re: CygUtils Version of zip (and Symlinks)

[Charles Wilson]

"Parker, Ron" wrote:
> 
> > > 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.
> 
> ISTM that the right behavior would be for cygwin to build a UNIX-ish (un)zip
> and for mingw to build a Windows style program.  As already pointed out
> cygwin should be thought of as "Unix on Win" and IMO mingw should be thought
> of as "as a free alternative for a good Win32 compiler".

Just to respond to a small part of this post:

mingw == 'free alternative for a good Win32 compiler'
cygwin-gcc -mno-cygwin == 'another free alternative for a good Win32
compiler'
cygwin-gcc -mno-cygwin != mingw

I'm not sure how this affects your argument below, but the difference
between cygwin-gcc -mno-cygwin and mingw does need to be considered.

--Chuck

> 
> I realize that cygwin and mingw are both supported by the same compiler, but
> supplying -mno-cygwin causes gcc to switch from cygwin to mingw behavior and
> __MINGW32__ becomes defined.
> 
> This may be more a question for cygwin-developers, but I hate crossposts and
> know most readers of that list at least review this one.  So, wouldn't it be
> appropriate when compiling without -mno-cygwin for the specs file to define
> "unix", "UNIX" and similar "standard" defines?  They seem to be checked for
> in newlib, zlib, X11, and many other sources?
> 
> Yes I know I can make this change in my local sources, but I prefer to work
> with standard sources and now seemed a good time to bring it up.  I have
> been wondering about it for some time.

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

Re: CygUtils Version of zip (and Symlinks)

[Cosmin Truta]

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

RE: CygUtils Version of zip (and Symlinks)

[Heribert Dahms]

Hi Jason,

I'd look at "tar" which stores symlinks by default
and it's "-h" option to force following them.

Bye, Heribert (heribert_dahms@icon-gmbh.de)

> -----Original Message-----
> From:	Chris Faylor [SMTP:cgf@cygnus.com]
> Sent:	Tuesday, May 23, 2000 21:42
> To:	cygwin@sourceware.cygnus.com
> Cc:	Jason.Tishler@dothill.com
> Subject:	Re: CygUtils Version of zip (and Symlinks)
> 
> On Tue, May 23, 2000 at 03:15:24PM -0400, Jason Tishler wrote:
> >Chris,
> >
> >Chris Faylor wrote:
> >> If I am understanding what you're saying correctly, you are
> essentially
> >> trying to break cygwin's encapsulation of symlinks.  There is no
> >> guarantee that a symlink will always begin with "!<symlink>" or
> >> even that the contents will contain any kind of magic denoting a
> symlink.
> >
> >That is why I called it a "very nasty hack."  I'm try to elicit the
> >proper way to read the (raw) contents of a Cygwin symlink file -- if
> >one exists.  Sounds like one doesn't.
> 
> Actually, my version of zip for cygwin has a '-y' option that stores
> symlinks
> and unzip seems to restore them correctly.
> 
> So, this is at least possible already.
> 
> cgf
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

Re: CygUtils Version of zip (and Symlinks)

[Jason Tishler]

Chris,

Chris Faylor wrote:
> There aren't any patches.  The -y option is a standard part of zip for UNIX so,
> of course, it works for cygwin too.

This whole zip journey (that was only suppose to take a "little" while)
started out with me accidentally building a Cygwin zip version as a
UNIX and not NT version.  But, when I tested out the -y option, for
some reason the symlinks got lost.  I'll try, try again.

Well, at least I learned lots of interesting (and hopefully useful)
tidbits and I had fun too.

Thanks,
Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corporation         Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com

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

Re: CygUtils Version of zip (and Symlinks)

[Earnie Boyd]

--- Chris Faylor <cgf@cygnus.com> wrote:
> On Tue, May 23, 2000 at 04:38:05PM -0400, Charles Wilson wrote:
> >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.
> >
> >Comments?
> 
> I agree (big surprise). 

So do I, and to the point that I remove the -D_WIN32 and -DWINNT from the specs
file.

Regards,



=====
---
   Earnie Boyd: < mailto:earnie_boyd@yahoo.com >
            __Cygwin: POSIX on Windows__
Cygwin Newbies: < http://www.freeyellow.com/members5/gw32/index.html >
           __Minimalist GNU for Windows__
  Mingw32 List: < http://www.egroups.com/group/mingw32/ >
    Mingw Home: < http://www.mingw.org/ >

__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

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

Re: CygUtils Version of zip (and Symlinks)

[Chris Faylor]

On Tue, May 23, 2000 at 04:38:05PM -0400, Charles Wilson wrote:
>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.
>
>Comments?

I agree (big surprise).  This is what we did for the cygwin CD.  IIRC,
it was somewhat difficult, but not impossible, to build zip as a UNIX
application for Windows.  We (i.e.  I) still screwed up the
binmode/textmode stuff though.  The version of zip on the CD only works
correctly if the file being accessed lives on a directory mounted with
binmode.  Sigh.

It sounds like the zip developers may have gone out of their way to make
it even more difficult from the sound of things.

cgf

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

Re: CygUtils Version of zip (and Symlinks)

[Charles Wilson]

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

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.

Comments?

--Chuck

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

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

Re: CygUtils Version of zip (and Symlinks)

[Charles Wilson]

About CygUtils' zip/unzip distribution:

The zip/unzip distro at CygUtils in the V1.1 tree was recently updated
(Apr 21, 2000). Before, I had zip-2.2 and unzip-5.32, built as unix
apps, but with locally maintained, cygwin specific patches. Cosmin Truta
told me that recent versions of those packages included cygwin support,
but that Cygwin was regarded as a Windows platform:

[Cosmin Truta wrote:]
> > Therefore, the compilation is
> > 
> > make -f win32/makefile.gcc
> > 
> > for both Cygwin and Mingw32.
> > 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__. 

I've been waiting for *my* chance to say this:

Patches gratefully accepted. :-)

--Chuck


Jason Tishler wrote:
> 
> DJ,
> 
> DJ Delorie wrote:
> > > 1. What is the best way to read the contents of a symlink file?  Can I
> > > use open or do I have to resort to CreateFile?
> >
> > Use readlink() and symlink() to read and create symbolic links.  These
> > also work under unix.
> 
> I had already considered the above but if I build zip/unzip as
> recommended then there is nothing in the archive to indicate that a
> file is a symlink except for the system attribute which is ambiguous.
> Hence, unzip will not be able to determine when to call symlink.
> 
> I will looking into building zip/unzip as a UNIX version and then
> see what else breaks...
> 
> Jason
>

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

Re: CygUtils Version of zip (and Symlinks)

[Chris Faylor]

On Tue, May 23, 2000 at 04:12:07PM -0400, Jason Tishler wrote:
>Chris Faylor wrote:
>> Actually, my version of zip for cygwin has a '-y' option that stores symlinks
>> and unzip seems to restore them correctly.
>
>Is your version of zip/unzip (or at least the patches) generally
>available?

There aren't any patches.  The -y option is a standard part of zip for UNIX so,
of course, it works for cygwin too.

cgf

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

Re: CygUtils Version of zip (and Symlinks)

[Jason Tishler]

Chris,

Chris Faylor wrote:
> Actually, my version of zip for cygwin has a '-y' option that stores symlinks
> and unzip seems to restore them correctly.

Is your version of zip/unzip (or at least the patches) generally
available?

Thanks,
Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corporation         Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com

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

Re: CygUtils Version of zip (and Symlinks)

[Chris Faylor]

On Tue, May 23, 2000 at 03:15:24PM -0400, Jason Tishler wrote:
>Chris,
>
>Chris Faylor wrote:
>> If I am understanding what you're saying correctly, you are essentially
>> trying to break cygwin's encapsulation of symlinks.  There is no
>> guarantee that a symlink will always begin with "!<symlink>" or
>> even that the contents will contain any kind of magic denoting a symlink.
>
>That is why I called it a "very nasty hack."  I'm try to elicit the
>proper way to read the (raw) contents of a Cygwin symlink file -- if
>one exists.  Sounds like one doesn't.

Actually, my version of zip for cygwin has a '-y' option that stores symlinks
and unzip seems to restore them correctly.

So, this is at least possible already.

cgf

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

Re: CygUtils Version of zip (and Symlinks)

[Jason Tishler]

DJ,

DJ Delorie wrote:
> > 1. What is the best way to read the contents of a symlink file?  Can I
> > use open or do I have to resort to CreateFile?
> 
> Use readlink() and symlink() to read and create symbolic links.  These
> also work under unix.

I had already considered the above but if I build zip/unzip as
recommended then there is nothing in the archive to indicate that a
file is a symlink except for the system attribute which is ambiguous.
Hence, unzip will not be able to determine when to call symlink.

I will looking into building zip/unzip as a UNIX version and then
see what else breaks...

Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corporation         Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com

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

Re: CygUtils Version of zip (and Symlinks)

[Jason Tishler]

Chris,

Chris Faylor wrote:
> If I am understanding what you're saying correctly, you are essentially
> trying to break cygwin's encapsulation of symlinks.  There is no
> guarantee that a symlink will always begin with "!<symlink>" or
> even that the contents will contain any kind of magic denoting a symlink.

That is why I called it a "very nasty hack."  I'm try to elicit the
proper way to read the (raw) contents of a Cygwin symlink file -- if
one exists.  Sounds like one doesn't.

> I am not sure why you aren't just using the same mechanism that something
> like tar uses to read and restore symlinks.

I'm not a zip expert (and trying not to become one) but the Cygwin
version of zip creates the archive as if it was produced by a native
Win32 zip.  Hence, I don't believe that there is a way to indicate that
a file is a symlink.

Beside, then one would have to extract using (the correspondingly
patched version of) unzip and could not use programs like WinZip.
Like I mentioned before, I feel that the bootstrapping potential is
very compelling.

Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corporation         Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com

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

Re: CygUtils Version of zip (and Symlinks)

[DJ Delorie]

> 1. What is the best way to read the contents of a symlink file?  Can I
> use open or do I have to resort to CreateFile?

Use readlink() and symlink() to read and create symbolic links.  These
also work under unix.

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

Re: CygUtils Version of zip (and Symlinks)

[Chris Faylor]

If I am understanding what you're saying correctly, you are essentially
trying to break cygwin's encapsulation of symlinks.  There is no
guarantee that a symlink will always begin with "!<symlink>" or
even that the contents will contain any kind of magic denoting a symlink.

I am not sure why you aren't just using the same mechanism that something
like tar uses to read and restore symlinks.

cgf

On Tue, May 23, 2000 at 02:25:14PM -0400, Jason Tishler wrote:
>Short Version:
>===== =======
>
>1. What is the best way to read the contents of a symlink file?  Can I
>use open or do I have to resort to CreateFile?
>
>2. Should the cygwin_conv_to_* functions (eg, cygwin_conv_to_win32_path)
>be enhanced to optionally not chase symlinks?
>
>Long Version:
>==== =======
>
>I have been fiddling around with the Cygwin version of zip that I
>downloaded from CygUtils ( http://cygutils.netpedia.net/ ).  My goal
>was to "improve" its support for symlinks.  I fairly quickly arrived
>at the following very nasty hack that does the job:
>
>    #define SYMLINK_COOKIE "!<symlink>"
>
>    int
>    rdsymlnk(path, buf, size)
>    const char *path;
>    char *buf;
>    unsigned size;
>    {
>      unsigned len = 0;
>
>      strcpy(buf, SYMLINK_COOKIE);
>      len = strlen(SYMLINK_COOKIE);
>      len += readlink(path, &buf[len], size - len);
>      buf[len++] = '\0';
>      return len;
>    }
>
>Using the above, I now have a version of zip that can generate
>archives (using -y and/or -S) that preserve symlinks.  These archives
>can be extracted via unzip, WinZip, etc. without losing any contained
>symlinks.  I find this great for bootstraping Cygwin installation.
>
>Obviously, using the value of SYMLINK_COOKIE breaks encapsulation and
>is a bad way to "read" the contents of a symlink file.  Reading the
>open man page (on Solaris), I found out the following:
>
>    If path is a symbolic link and O_CREAT and O_EXCL  are  set,
>    the link is not followed.
>
>Although I was skeptical, I tried the above with Cygwin and I wasn't
>disappointed -- it didn't work.
>
>Next, I started reading the code in path.cc from the Cygwin winsup
>source to see how Cygwin implements readlink().  Sure enough, I found
>out that the contents of a symlink is ultimately read via CreateFile
>and ReadFile.
>
>So, I decided redo my hack by replacing readlink with a new function
>that I call (for argument sake) Cygwin_readlink.  Cygwin_readlink
>will use CreateFile to open the symlink file.  Hence, I need to call
>cygwin_conv_to_win32_path to convert the POSIX path to a Win32 path.
>Unfortunately, this chases the symlink...bummers!  Of course, I can
>play games like calling cygwin_conv_to_win32_path on the dirname part
>of the path and then concatenate the results with the basename part.
>
>It seems like I'm missing something, so this brings me back to the
>short version:
>
>1. What is the best way to read the contents of symlink file?  Can I
>use open or do I have to resort to CreateFile?
>
>2. Should the cygwin_conv_to_* functions (eg, cygwin_conv_to_win32_path)
>be enhanced to optionally not chase symlinks?
>
>BTW, I will post my zip patches once I figure out the best way to
>handle symlinks.
>
>FYI, the current CygUtils version of zip does not properly handle
>absolute pathnames as in the following:
>
>    $ zip -r jt.zip /home/jt # H:\ is mounted as /home/jt
>
>It will treat /home/jt above as X:\home\jt, where X is your current
>drive, and not as H:\.  Hence, it is missing (at least) one call to
>cygwin_conv_to_win32_path.  But, cygwin_conv_to_win32_path chases
>symlinks...

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

CygUtils Version of zip (and Symlinks)

[Jason Tishler]

Short Version:
===== =======

1. What is the best way to read the contents of a symlink file?  Can I
use open or do I have to resort to CreateFile?

2. Should the cygwin_conv_to_* functions (eg, cygwin_conv_to_win32_path)
be enhanced to optionally not chase symlinks?

Long Version:
==== =======

I have been fiddling around with the Cygwin version of zip that I
downloaded from CygUtils ( http://cygutils.netpedia.net/ ).  My goal
was to "improve" its support for symlinks.  I fairly quickly arrived
at the following very nasty hack that does the job:

    #define SYMLINK_COOKIE "!<symlink>"

    int
    rdsymlnk(path, buf, size)
    const char *path;
    char *buf;
    unsigned size;
    {
      unsigned len = 0;

      strcpy(buf, SYMLINK_COOKIE);
      len = strlen(SYMLINK_COOKIE);
      len += readlink(path, &buf[len], size - len);
      buf[len++] = '\0';
      return len;
    }

Using the above, I now have a version of zip that can generate
archives (using -y and/or -S) that preserve symlinks.  These archives
can be extracted via unzip, WinZip, etc. without losing any contained
symlinks.  I find this great for bootstraping Cygwin installation.

Obviously, using the value of SYMLINK_COOKIE breaks encapsulation and
is a bad way to "read" the contents of a symlink file.  Reading the
open man page (on Solaris), I found out the following:

    If path is a symbolic link and O_CREAT and O_EXCL  are  set,
    the link is not followed.

Although I was skeptical, I tried the above with Cygwin and I wasn't
disappointed -- it didn't work.

Next, I started reading the code in path.cc from the Cygwin winsup
source to see how Cygwin implements readlink().  Sure enough, I found
out that the contents of a symlink is ultimately read via CreateFile
and ReadFile.

So, I decided redo my hack by replacing readlink with a new function
that I call (for argument sake) Cygwin_readlink.  Cygwin_readlink
will use CreateFile to open the symlink file.  Hence, I need to call
cygwin_conv_to_win32_path to convert the POSIX path to a Win32 path.
Unfortunately, this chases the symlink...bummers!  Of course, I can
play games like calling cygwin_conv_to_win32_path on the dirname part
of the path and then concatenate the results with the basename part.

It seems like I'm missing something, so this brings me back to the
short version:

1. What is the best way to read the contents of symlink file?  Can I
use open or do I have to resort to CreateFile?

2. Should the cygwin_conv_to_* functions (eg, cygwin_conv_to_win32_path)
be enhanced to optionally not chase symlinks?

BTW, I will post my zip patches once I figure out the best way to
handle symlinks.

FYI, the current CygUtils version of zip does not properly handle
absolute pathnames as in the following:

    $ zip -r jt.zip /home/jt # H:\ is mounted as /home/jt

It will treat /home/jt above as X:\home\jt, where X is your current
drive, and not as H:\.  Hence, it is missing (at least) one call to
cygwin_conv_to_win32_path.  But, cygwin_conv_to_win32_path chases
symlinks...

Thanks,
Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corporation         Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com

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