X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW
X-Spam-Check-By:	sourceware.org
Mime-Version:	1.0 (Apple Message framework v753.1)
Message-Id:	<CC11356C-47B3-4FD0-9A58-89A9691A52D8@von-campe.com>
To:	cygwin AT cygwin DOT com
From:	Alfred von Campe <alfred AT von-campe DOT com>
Subject:	Strange symlink behaviour
Date:	Wed, 3 Mar 2010 15:59:12 -0500
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

Do symbolic links work over CIFS?  I'm having a really strange  
problem with symlinks.  Here is the story.

We have a small NAS box that is accessed via both NFS and CIFS.  The  
former is needed for the actual production access of the files on the  
share, but the latter is used to update the contents of the share.   
That is, we need to access the files from Linux via NFS, but want to  
update the files on Windows via CIFS.  The problem is that we need to  
create a symlink on the share, and to make it easier/possible to  
update the share from Windows we create a tar file that contains the  
three files we need:

   file_with_version_v1.0.3.abc
   file.abc ->  file_with_version_v1.0.3.abc
   other_file.def

If the share we want to populate with these files is empty,  
everything works fine.  However, when we try to install the new  
release on top of an existing release, we run these commands:

   rn -fv //path/to/share/*
   tar xvf //path/to/temp/release.tar -C //path/to/share

If the new version is 1.0.4, I expect the following files in the  
share after running those commands:

   file_with_version_v1.0.4.abc
   file.abc ->  file_with_version_v1.0.4.abc
   other_file.def

But instead, we get this (when looked at via NFS):

   file_with_version_v1.0.4.abc
   file.abc ->  file_with_version_v1.0.3.abc
   file.abc.lnk
   other_file.def

Note that the link is pointing to the old file and there is a  
shortcut added to the directory. Upon further inspection, when we run  
the "rm -f //path/to/share/*" command the directory appears empty  
when checking it on Windows or via CIFS.  However, when accessing it  
via NFS, I can still see the symlink.  So when the tar file is  
untar'ed, the symlink does not get overwritten and a shortcut is  
created instead.

We are still running Cywin V1.5 on the manufacturing floor, and  
updating to V1.7 is not feasible at the moment.  I think Cygwin uses  
some special tricks to get symlinks to work on Windows, but I don't  
quite understand how it works.  Any ideas what may be going on?

Thanks,
Alfred


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

- Raw text -