On Mon, Jul 05, 2004 at 02:08:44PM -0400, Larry Hall wrote: >At 06:54 AM 7/5/2004, you wrote: >>I (tried to) read the FAQ carefully and did'nt find a clue. >> >>The problem is for the packaging of applications that install some of >>their files in a directory that is a link. On NT4 I have a strange >>behavior: the directory is hidding the link and the files didn't mix. >>OK, I know that my english is not very clear (sorry but I'm french >>:->), >> >>so let's explain with an example: >> >>1/ I am porting the xlockmore application. This is an X11 program and >>after being compiled and configured the X11 resource files will be >>installed in $prefix/lib/X11/app-defaults (prefix is /usr/X11R6) >> >>2/ I package the file within a bzip2 compress tar-ball, and this tar >>(for example for the motif GUI xmlock) contains: >>usr/ >>usr/X11R6/ >>usr/X11R6/bin/ >>usr/X11R6/bin/xmlock.exe >>usr/X11R6/lib/ >>usr/X11R6/lib/X11/ >>usr/X11R6/lib/X11/app-defaults/ >>usr/X11R6/lib/X11/app-defaults/XmLock
>>3/ after using setup to install this package I have in /usr/X11R6 a >>directory named app-defaults (which is "hiding" the symlink for the >>initial app-defaults which is a link to /etc/X11/app-defaults and is >>created when installing xorg): > >Right. This is standard 'tar' behavior. There's nothing Cygwin >specific here. 'tar's info page has this to say: Actually, I think what is being described is probably that setup.exe's tar emulation doesn't know about .lnk style symlinks and so it is capable of restoring a symlink to a file in a directory which already has a file or directory with the same name as the symlink. The workaround for this should be to set the CYGWIN environment variable to CYGWIN=nowinsymlinks prior to creating the symlink. setup.exe knows about the non-lnk style symlinks so it may do a better job at detecting this situation. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
