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:	<DDFE2CAB87ECD311B02D0000929695E20EBCDB@WOTAN>
From:	"Tweedy, Laura" <l DOT tweedy AT clairvoyancecorp DOT com>
To:	"'cygwin AT sourceware DOT cygnus DOT com'" <cygwin AT sourceware DOT cygnus DOT com>
Subject:	ln -f changes permissions on NT
Date:	Mon, 18 Sep 2000 15:53:43 -0400
MIME-Version:	1.0
X-Mailer:	Internet Mail Service (5.5.2448.0)

Hello...

I am running into permission problems with ln -f.  I have a file that
is read-only and I want it to remain so.  I am making a hard link to
it in another location.  This link is done in a makefile which uses
ln -f to make the link.  The link works fine, but if making the target
requires that it be removed first, the permissions become read-write.

I believe this is the result of the target being forcibly removed
before it is linked again.  I saw in the source (for ln or _unlink, I
can't remember) that when files are read-only but are being removed
anyway, their permissions are changed and the remove is tried again.
I think this "transient" permission for the file is sticking around
longer than intended.

On Unix (I tried Solaris and Linux), ln -f keeps the permissions of
the source file, even if the target has to be removed.  On NT, the
permissions necessary to removed the target stay around.

This problem of transient permissions is evident in rm -f too.  On
Unix, rm -f keeps the permissions on the other links while removing
one of the links.  On NT, the permissions for removing stay around.

Below is a transcript showing NT vs. Solaris and their behaviours.
I am looking for a work-around, but I thought I would report it
anyway in case it hasn't been reported.  I'm running with the 1.1.2
cygwin DLL (I think).  I didn't see in the changes for 1.1.4 that this
was fixed, but I haven't tried it.  My apologies if it's fixed there.

Thanks!
laura

NT:
d:\>ls -l foo
-r--r--r--   1 tweedy   Administ       13 Sep 18 15:35 foo

d:\>ln -f foo bar

d:\>ls -l foo bar
-r--r--r--   2 tweedy   Administ       13 Sep 18 15:35 bar
-r--r--r--   2 tweedy   Administ       13 Sep 18 15:35 foo

d:\>ln -f foo bar

d:\>ls -l foo bar
-rw-r--r--   2 tweedy   Administ       13 Sep 18 15:35 bar
-rw-r--r--   2 tweedy   Administ       13 Sep 18 15:35 foo

d:\>

Solaris:
quadsun: ~ 20 > ls -l foo
-r--r--r--   1 tweedy   users         12 Sep 14 16:06 foo
quadsun: ~ 21 > ln -f foo bar
quadsun: ~ 22 > ls -l foo bar
-r--r--r--   2 tweedy   users         12 Sep 14 16:06 bar
-r--r--r--   2 tweedy   users         12 Sep 14 16:06 foo
quadsun: ~ 23 > ln -f foo bar
ln: foo and bar are identical
quadsun: ~ 24 > ls -l foo bar
-r--r--r--   2 tweedy   users         12 Sep 14 16:06 bar
-r--r--r--   2 tweedy   users         12 Sep 14 16:06 foo
quadsun: ~ 25 > 



NT:
d:\>ls -l foo bar
-r--r--r--   2 tweedy   Administ       13 Sep 18 15:35 bar
-r--r--r--   2 tweedy   Administ       13 Sep 18 15:35 foo

d:\>rm -f bar

d:\>ls -l foo
-rw-r--r--   1 tweedy   Administ       13 Sep 18 15:35 foo

d:\>

Solaris:
quadsun: ~ 29 > ls -l foo bar
-r--r--r--   2 tweedy   users         12 Sep 14 16:06 bar
-r--r--r--   2 tweedy   users         12 Sep 14 16:06 foo
quadsun: ~ 30 > rm -f bar
quadsun: ~ 31 > ls -l foo
-r--r--r--   1 tweedy   users         12 Sep 14 16:06 foo
quadsun: ~ 32 > 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com

- Raw text -