delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2005/07/16/19:00:57

Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
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
From: ericblake AT comcast DOT net (Eric Blake)
To: Barry Demchak <vendors AT tpsoft DOT com>
Cc: cygwin AT cygwin DOT com
Subject: Re: cannot create temp file for here document
Date: Sat, 16 Jul 2005 23:00:40 +0000
Message-Id: <071620052300.27340.42D99198000046BC00006ACC22073000330A050E040D0C079D0A@comcast.net>
X-Authenticated-Sender: ZXJpY2JsYWtlQGNvbWNhc3QubmV0

> 
> Attached please find the strace_unlink.out you requested. To get this, I 
> started Cygwin and did the following:
> 
> cd /tmp
> cat >foo
> blah blah blah ^Z
> strace -o strace_unlink.out unlink foo
> 
> Looking at the trace, I can see where unlink returns a 2, which would give 
> the error ... but unlink also deletes the file (I checked). I checked the 
> Win32 documentation on unlink (both on CD and at MSDN) and there are no 
> indications of weirdness.

That is bizarre, but you are probably right that it has to do with
the fact that you are on an NT machine but with a FAT file system.
I'll defer to the primary cygwin developers to see if they agree.

> 
> Attached please find the strace_bash_lite.out dump as requested. I executed 
> this from the /tmp directory, too.
> 
> Looking at the track, I can see the same unlink failure as in the unlink trace.
> 
> When I create foo in the /tmp directory and then do an ls -l on it, I get:
> 
> -rw-r--r--  1 bdemchak None 15 Jul 16 11:20 foo
> 
> Windows claims that the owner is "Everyone", which is a virtual group that 
> supposedly really does contain everyone.
> 
> I can add only a few tidbits.
> 
> One is to point out that this partition is a FAT32 partition ... one 
> wonders if there may be problems because it's not an NTFS partition. 
> Considering that it's my boot partition, I would change it ... but not 
> lightly ... and only with very good reason (which this might be).

FAT has very little in its favor - it has no file permissions to speak
of, can't do hard links, and in general is not as powerful as NTFS.
Upgrading certainly would improve the situation.

> 
> In playing around with this, I'm getting the feeling that cygwin maintains 
> a shadow permission list for each file. My best guess right now is that 
> this shadow list (if it exists) is getting out of sync with the Windows 
> directory contents. Were this the case, cygwin might be relying on the 
> shadow list for part of an operation (like unlink) and Windows for another. 
> If the two are out of sink, we'd see something like what we're seeing.

No, cygwin uses Windows notions of permissions, which are keyed
to Windows SID, and maps that to POSIX permissions.  If Windows
can't report the correct permissions (and remember, FAT drives
don't store full permissions like NTFS does), then cygwin can't improve
the situation.   As to editing your passwd file, as long as you leave
SIDs alone, you should be able to edit user name, group id, and
preferred shell without any adverse effects.  See
http://cygwin.com/cygwin-ug-net/cygwin-ug-net.html#ntsec

> 
> Does this lead you anywhere??
> 
> Thanks!

Hope I've been some help.

--
Eric Blake



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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019