Subject: Re: cannot create temp file for here document
From: Barry Demchak <[email-masked]>
To: Eric Blake <[email-masked]>
Cc: [email-masked]
Date: Sat, 16 Jul 2005 11:49:46 -0700

OK ... end-posted ... see below ...

At 06:12 AM 7/16/2005, Eric Blake wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Ugh, top-posting, reformatted.
> >> Nope, since you don't define TMPDIR, bash is trying to use /tmp.  And the
> >> location of /tmp is probably c:\cygwin\tmp, although you didn't follow
> >> the directions to attach cygcheck output, so I can't prove that.
> >>
> >> Please show the output of:
> >>
> >> $ ls -l / /tmp /cygdrive/c
> >> $ getfacl / /tmp /cygdrive/c
>
>Shoot - I meant "ls -ld", to limit the listing to just those three
>directories instead of their contents, but it's okay because the
>information is still there.
>
> >>
> >> My guess is that there are ACLs at play, so that even though ls shows the
> >> directory as writable, an ACL is preventing your user id from actually
> >> creating the temp file.
> >
> > Please find attached my cygcheck.out file.
>
>Let's see - no CYGWIN variable defined, and win2k, so you are running
>ntsec (by default).  /tmp is indeed mounted to c:\cygwin\tmp.  You're
>pretty up-to-date on packages.  So far, so good.
>
> >
> > Please find attached the "ls -l / /tmp /cygdrive/c" output you
> > requested. Note that the error message "ls: /cygdrive/c/pagefile.sys: No
> > such file or directory" was printed to stderr immediately after listing
> > the "/" directory.
>
> > /:
> > drwxr-xr-x   2 bdemchak None    0 Jul 14 23:19 tmp
> > /cygdrive/c:
> > drwxr-xr-x  11 bdemchak None        0 Jul 14 23:17 Cygwin
>
>Weird, no extra ACLs, which would normally be there when running ntsec.
>So those directories are indeed writable by only the bdemchak user, and it
>seems like it should succeed.
>
> >
> > Please find attached the "getfacl / /tmp /cygdrive/c" output you requested.
>
>This confirms that there are no additional ACLs, so that strikes my theory
>that bash was misinterpreting permissions.  Perhaps someone else can
>deduce what's going wrong?
>
> > Please find attached the "bash -xv" output you requested.
>
>It looks like your trace cut off the first few lines of execution of
>/etc/profile, but that's okay; it still included all the useful
>information.  The result of bash not being able to create the temp file is
>that none of the /etc/profile.d/*.sh scripts are being run at login.
>
> > There's more, though ... as I collected this information, I noticed a
> > very peculiar effect that I'm betting has something to do with this. If
> > I "ls >foo", I'm fine. If I "unlink foo", foo gets deleted, but I also
> > get a spurious error message:
> >
> > bdemchak@malex ~
> > $ unlink foo
> > unlink foo
> > + unlink foo
> > unlink: cannot unlink `foo': No such file or directory
> >
> > Like I said, foo gets deleted, but then there's the error message. This
> > smells like it's all tied together, but I can't quite put my finger on it.
>
>Odd, and yes it might be related.  This time, it would be nice to have the
>strace_unlink.out file from "strace -o strace_unlink.out unlink foo".  An
>strace of bash would also be nice, but because it is so big, try the
>following to prune it to just the locations where bash tries to open its
>temporary file (bash uses the prefix sh-thd for all temporary here-doc
>files), then just attach strace_bash_lite.out to your reply:
>
>$ strace -o strace_bash_full.out bash -li
>$ exit
>$ grep -C 20 sh-thd strace_bash_full.out > strace_bash_lite.out
>
> >
> > FYI, I *can* create files in tmp using "cat >foo" ... no permission
> > violation or any other error ... works fine.
>
>I'm assuming you did that from within /tmp, and >foo is taken care of by
>bash.  So I have no idea why bash can create /tmp/foo and not temporary files.
>
>- --
>Life is short - so eat dessert first!
>
>Eric Blake             [email-masked]
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.1 (Cygwin)
>Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFC2Qe984KuGfSFAYARAmwAAJwO1h2OaedeMrxriqUA/KbSq2fGLwCg005C
>7UtazvgRPZR7QZN7Mp4217s=
>=1wgA
>-----END PGP SIGNATURE-----

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.

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

Also, I am enclosing my passwd file just in case. The user ID I use is 
"Barry Demchak". Early on, we edited the passwd file to shorten the name to 
bdemchak for cygwin purposes. The reason I have not mentioned this until 
now is that the problem also manifests itself with a one-word userID 
("dumbass").

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.

Does this lead you anywhere??

Thanks!

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