Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-Id: <4.2.0.58.20010425171410.00a04ea0@ics.u-strasbg.fr>
X-Sender: muller AT ics DOT u-strasbg DOT fr
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 25 Apr 2001 17:16:40 +0200
To: cygwin AT cygwin DOT com
From: Pierre Muller <muller AT cerbere DOT u-strasbg DOT fr>
Subject: Re: Symbol link trouble ?
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit

Corinna wrote
 >On Wed, Apr 25, 2001 at 02:09:48PM +0200, Pierre Muller wrote:
 >> At 13:13 25/04/01 , vous avez écrit:
 > > >Could be a buffering technique of W95. I have just read the Microsoft
 > >KB article Q128932 "How Windows 95 Resolves Shortcut Links" but it
 > >doesn't obtain any additional information.
 >
 >   Using strace seems to indicate that the file test.h.lnk is read!
 >
 >Sure it's read. Cygwin doesn't see if the file is actually read or
 >if the file content is read from an already existing OS buffer.
 >
 >> Should I send you the binary link file and the strace output.
 >
 >Actually I have no hope to find something strange from the strace
 >but it doesn't hurt. Send the strace (not the link file which
 >is useless to me) as gzipped attachment to mailto:vinschen AT redhat DOT com.
 >

You are probably right:

   there is no read after the call to CreateFileA
for the symlink disk file)

   I now tested it by first setting the link in the Windows explorer (WE)
and testing this, I found out the following:

   setting a link with WE works for cygwin bash
it simply reports the win32 path of the target file.

   Changing it with WE works normally and is reflected correctly.
  But removing the file in bash are setting it to another
target makes the windows link reappear unchanged !

   Note that if  remove the link from inside WE then
the subsequent call to ln works correctly
(the link is to the corrct file,
but in WE I still get no target file written !)

   It seems like WE is doing something more than just deleting
the  test.h.lnk disk file !




Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller AT ics DOT u-strasbg DOT fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple