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