# Cygwin or Windows: file permission functions are broken

#### Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

•  Subject
• Author
• Posted on
My apologies for asking a Cygwin- or Windows-specific question here,
but it's also Perl-specific, and I'm not sure of a better
easy-to-access place.

I looked in perlfaq5 and didn't see it discussed there, possibly
because it's a Cygwin or Windows problem in particular -- but this HAS
to be a common problem.  I tried some Googling, but it's hard to
search for "w", and I couldn't think of effective search terms.

I'm using a pretty recent Cygwin, but I don't know how to find out a
version number or date.  "cd"ed into an NTFS partition.  Environment
variable CYGWIN is "tty ntsec".

The current directory is owned by group Administrators; my user ID is
can do any regular commands that create or delete files (Cygwin touch,
CMD.EXE copy, anything).

But
perl -e 'print(-w "." ? "yes\n" : "no\n")'
prints "no", and the same for -r and -x.
Possibly related to "ls -ld" outputting this:
drwx------+ 30 ???????? none 0 Jan 15 11:44 .

I noticed this when I couldn't get File::Temp to work with DIR=>'.'
[footnote 2], because of its code

# Check that the parent directories exist
# Do this even for the case where we are simply returning a name
# not a file -- no point returning a name that includes a directory
# that does not exist or is not writable

unless (-d $parent) {$} = "Parent directory ($parent) is not a directory"; return (); } unless (-w$parent) {
$} = "Parent directory ($parent) is not writable\n";
return ();
}
[footnote 1]

Question 1: is there any way I can get Perl's -r / -w / -x functions
to work?  Is this indeed an FAQ question, or should I actually file a
bug report with the Cygwin group?

Question 2: Is there another module that's shipped with Perl that I
could use instead of File::Temp?  I don't know of a way to tell all
the modules that are installed.  (I'd really prefer not to depend on
yet another module needing to be installed.)  IO::File::new_tmpfile()
doesn't take a directory name [2].  POSIX's
char * tempnam(const char *tmpdir, const char *prefix)
is not implemented in module POSIX::...

I guess I'll just adapt the code from perlfaq5 ...

Question 3: ... but why is it wrapped in a BEGIN block?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[1] I consider that a design flaw.  I believe that the best way to
test that an operation will succeed is simply to try to do it, and
catch the failure.  (When the operation indicates all errors, and when
it is atomic, either succeeding completely or failing with no
residure.)

[2] There are reasons that I don't use TMPDIR, TEMP, or TMP.  They are
irrelevant to this problem.  Really. ...

... if you insist: I often run the Perl program outside of a Cygwin
window.  Even when TMPDIR is set in Windows syntax as C:\tmp, on
startup Perl transmogrifies it to /tmp (or whatever, per cygpath -u).
The Perl program calls non-Cygwin-aware programs, so they have to get
non-Cygwin paths like "e:\foo\bar" instead of "/CM/foo/bar".  Since
the Perl program is running in a cmd.exe window, Cygwin programs are
not in the Path ... meaning I can't just run "cygpath -w".  I don't
want to hard-code Path directories into the script.

But "." is a directory name that works in both Cygwin and non-Cygwin.
It's not much of a stretch to insist that they run the program in a
writable directory ... as long as Perl realizes that it's writable,
dammit!!1!

--
Tim McDaniel, tmcd@panix.com

## Re: Cygwin or Windows: file permission functions are broken

I'm running ActiveState 5.8.8 and my Perl doesn't act like your version.
C:\Documents and Settings\Administrator>perl -e "print (-w '.' ? 'yes' :
'no')"
yes
C:\Documents and Settings\Administrator>perl -e "print (-d '.' ? 'yes' :
'no')"
yes
C:\Documents and Settings\Administrator>perl -e "print (-r '.' ? 'yes' :
'no')"
yes

I have also never seen any paths "transmogrified" by Perl.  Have you tried
installing and running your program using an ActiveState build instead of a
version compiled under Cygwin?

Not sure what your issue with File::Temp is, but this is a standard module
included in the ActiveState distribution and works just like the Unix
version.

## Re: Cygwin or Windows: file permission functions are broken

&c.

Thanks for the datum.  I'll consider installing ActiveState, though I
don't like the idea of two Perls.

It's Cygwin's perl port doing it: when it starts the program, it
converts TMP, TEMP, TMPDIR, PATH, and probably certain other
environment variables to Cygwin path syntax (UNIXy).  It's not every
variable: I set FROG to 'C:\home' and it remains unchanged.

Not so much of one.  My main beef is with -r / -w being inaccurate.

tmpdir in File::Temp (specifically, the Cygwin.pm subclass) finds the
first writable directory (as determined by -w) in

$ENV /tmp C:/temp As mentioned, Cygwin mutates TMPDIR into its own filename syntax. For example, on my system it changed c:\tmp into /tmp/1. That all works fine, except - when -w gives an incorrect answer, you get a different tmpdir. In particular, I had write permission to /tmp/1, yet "-w '/tmp/1'" returned false, so it went on to /tmp. - when you have to run programs that require Windows paths, you need to run the filename through "cygpath -w" to get the Windows syntax again, and for increasingly silly-looking reasons I'm reluctant to do that. -- Tim McDaniel, tmcd@panix.com ## Re: Cygwin or Windows: file permission functions are broken You don't need two Perls, only the ActiveState one. You can still run Cygwin programs within ActiveState Perl, but without all the headaches that you have experienced. The ActiveState version is a port that makes Perl behave the same way on both unix and Win32 in as much this is possible. Cygwin only emulates a POSIX enviroment and there are bigger differences between unix and Win32 than just POSIX. ## Re: Cygwin or Windows: file permission functions are broken Tim McDaniel wrote: Try the Cygwin mailing list. IMHO "tty" is bad... The "+" above indicates that the permissions are "special". Stated differently, the Windows permissions mask is way larger of a set than the Unix permissions mask. The "+" is saying that there are Windows permissions to this directory (or file) that simply cannot be represented in POSIX file permissions. This is probably the key to your misunderstanding. Change the permissions of the directory such that they fall within possibility of the simplistic POSIX standard. I believe File::Temp will use$TMP. My $TMP -> C:\Cygwin\tmp, or in POSIX terms /tmp in Cygwin. My /tmp says:$ ll -d /tmp
drwxrwxrwt 3 Andrew DeFaria None 0 Jan 16 00:05 /tmp/

No "+".

BEGIN?

Actually I see them as a viable alternative.

Running within a Cygwin "window" (Whatever that is) or not is not the issue.

I think you're confused. There is not C:\tmp in Cygwin terms. There is
only /tmp. /tmp *translates* (not transmogrifies) to C:\Cygwin\tmp and
always has. Said differently, your C:\tmp is not Cygwin's notion of $TMP. However many Windows programs understand the syntax of C:/foo/bar You can, and IMHO, should, add C:\Cygwin\bin to your user level PATH environment variable. Again, IMHO it's a very reasonable and understandable thing to do and require. Again, MHO. The definition of "writable" differs between the POSIX world and the Windows world. That's the essence of your misunderstanding. -- Andrew DeFaria <http://defaria.com First to come are the midgets, a monkey and a kid. Followed by those two one-armed jugglers, the ego and the id - Gordon Lightfoot ## Re: Cygwin or Windows: file permission functions are broken ... <http://www.cygwin.com/cygwin-ug-net/using-cygwinenv.html explains it. I don't find the explanation very clear (does "the Windows console" refer to a cmd window or what?, but I'll look at it some more. You might have been kind enough to *explain* what you thought the misunderstanding was. When I searched "man perlfunc" to quote you the line that I remembered, -w File is writable by effective uid/gid. I also ran across lines that explained the problem: The interpretation of the file permission operators "-r", "-R", "-w", "-W", "-x", and "-X" is by default based solely on the mode of the file and the uids and gids of the user. There may be other reasons you can't actually read, write, or execute the file: for example network filesystem access controls, ACLs (access control lists), read-only filesystems, and unrecognized executable formats. Note that the use of these six specific operators to verify if some operation is possible is usually a mistake, because it may be open to race conditions. Also note that, for the superuser on the local filesystems, the "-r", "-R", "-w", and "-W" tests always return 1, and "-x" and "-X" return 1 if any execute bit is set in the mode. Scripts run by the superuser may thus need to do a stat() to determine the actual mode of the file, or temporarily set their effective uid to something else. If you are using ACLs, there is a pragma called "filetest" that may produce more accurate results than the bare stat() mode bits. When under the "use filetest 'access'" the above-mentioned filetests will test whether the permission can (not) be granted using the access() family of system calls. Also note that the "-x" and "-X" may under this pragma return true even if there are no execute permission bits set (nor any extra execute permission ACLs). This strangeness is due to the underlying system calls' definitions. Note also that, due to the implementation of "use filetest 'access'", the "_" special filehandle won't cache the results of the file tests when this pragma is in effect. Read the documentation for the "filetest" pragma for more information. Specifically, _ *will* cache any other test bits, like -e, -d, and such. The "use filetest access" pragma does work on Cygwin (in the latest regular version). I created a directory and made it read/write only to Administrators. In it,$ touch frog   # no error, so it works OK
$perl -e 'print (-w "." ? "yes\n" : "no\n")' no$ perl -e 'use filetest access; print (-w "." ? "yes\n" : "no\n")'
yes

Unfortunately,
- File::Temp or File::Spec uses _ extensively
- "use filetest 'access'" has lexical scope, so it can't reach into
File::Temp or File::Spec

So I consider it a bug in File::Temp that I can't get around.

No, thank you.  The permissions work well for my purposes as they are.

Yes, BEGIN, as in "the code from perlfaq5":

How do I make a temporary file name?

... If you're committed to creating a temporary file by hand, use
the process ID and/or the current time-value.  If you need to have
many temporary files in one process, use a counter:

BEGIN {
use Fcntl;
my $temp_dir = -d '/tmp' ? '/tmp' :$ENV || $ENV; my$base_name = sprintf "%s/%d-%d-0000", $temp_dir,$$, time; sub temp_file { local *FH; my$count = 0;
until( defined(fileno(FH)) || $count++ > 100 ) {$base_name =~ s/-(\d+)$/"-" . (1 +$1)/e;
# O_EXCL is required for security reasons.
sysopen FH, $base_name, O_WRONLY|O_EXCL|O_CREAT; } if( defined fileno(FH) ) { return (*FH,$base_name);
}
else {
return ();
}
}

}

When I implemented it, with a cache of filenames, a destroyer, and a
signal handler, it did not need to be in a BEGIN block.

It is an issue of why I don't use TMP, cygpath, and such.

By a "Cygwin window", I refer to rxvt or some other run of bash.  In
.bashrc, I set a Cygwin-aware PATH.  The programs I pick up are mostly
Cygwin-aware, in practice.

In a cmd.exe window, it has a Windows-aware Path, and I don't put
Cygwin programs into it.  The programs I run want only Windows file
syntax.

My apologies for being imprecise.  /tmp actually translates to
[root of the Cygwin installation]\tmp.  I set the root of the Cygwin
installation to C:\ instead of C:\cygwin, so for me, /tmp DOES
translate to C:\tmp.  That's because I got too tired of having to
insert and delete "cygwin\" when converting paths by hand
(copying-and-pasting commands from one command window or file to
another), and to heck with setup.exe's deprecation warning.

And don't get snippy about informal / slangy terminology.
"transmogrify" is a just a sillier-sounding way of writing
"translate".

But apparently not the syntax of just "/tmp", judging by the error
messages from Windows programs, and /tmp is what they were receiving
when I thought it was passing C:\tmp.

POSIX defines ACLs quite well.  Say, rather, that Perl's
implementations of -r / -w / -x take a shortcut that works in practice
on most UNIXy systems, since few people there use ACLs, but produces
an unuseful effect on ACL-heavy systems.

--
Tim McDaniel, tmcd@panix.com