This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: problems with symbolic links


This is actually an old known problem that exists with older versions of samba, I know that this works correctly at least since samba 3.0.23d, and I know that, for example, samba 3.0.2 does not. This is still true for cygwin 1.7 which uses a file attribute, rather than the .lnk extension.



alf salte wrote:
My setup:

I have a network drive seen in windows as S: and has file type NTFS. Actually, the file system is ext3 but it seems the software on the network drive makes it appear as NTFS to windows - properties in windows describe it as NTFS.

In cygwin this is seen as /cygdrive/s and when I try to create a symbolic link on the drive it appears to be working correctly:

ln -s foo bar

creates a symbolic link bar.lnk that contains a reference to the file foo.

The problem is when I try to use this symbolic link. For one thing, scripts that then try to open bar get a surprise since the filename is really bar.lnk but worse is the fact that neither bar nor bar.lnk opens up foo. less bar just report file not found and less bar.lnk simply opens the link and dumps out the binary data in it where one of the fields contain the file foo.

What am I doing wrong? I did see that there was some problem if you did not have the drive mounted as "system" but the drive /cygdrive/s is mounted as (remote,system) so I am at a loss as to what is wrong.

Would appreciate any help in the matter. As it is, any installation script or make script that make a link "ln -s foo.c bar.c" will not be able to use 'bar.c' to refer to the file and gcc does not understand that bar.c.lnk is supposed to be a C source file - nor is it a C source file since it is a link etc etc. Also, ls -l does not report the file as 'l' in the first character, it reports the link as a regular file. Is there a bug in fstat()?

I would guess that open("foo",..) should check if the file "foo" is not found, if there is a file "foo.lnk" and then open that file and find the file it references etc. Not sure exactly how or where this is handled in the code. Checking cygwin.dll source code there is a path name resolver class and it does appear to add a ".lnk" extension but it appears to only apply to directory names in a path and not sure exactly under which conditions that code is enabled from a regular open() function.

Alf



      _________________________________________________________
Alt i ett. Få Yahoo! Mail med adressekartotek, kalender og
notisblokk. http://no.mail.yahoo.com

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple




--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]