Re: Cygwin or Windows: file permission functions are broken
- From: tmcd@xxxxxxxxx (Tim McDaniel)
- Date: Sat, 17 Jan 2009 00:25:26 +0000 (UTC)
In article <4970331e$0$48226$815e3792@xxxxxxxxxxxxxx>,
Andrew DeFaria <Andrew@xxxxxxxxxxx> wrote:
....
Tim McDaniel wrote:
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'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".
IMHO "tty" is bad...
<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.
The current directory is owned by group Administrators; my user ID
is in group Administrators; group Administrators has full
control. So I 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 .
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.
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.
Question 1: is there any way I can get Perl's -r / -w / -x
functions to work?
Change the permissions of the directory such that they fall within
possibility of the simplistic POSIX standard.
No, thank you. The permissions work well for my purposes as they are.
I guess I'll just adapt the code from perlfaq5 ...
Question 3: ... but why is it wrapped in a BEGIN block?
BEGIN?
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{TMPDIR} || $ENV{TEMP};
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.
... if you insist: I often run the Perl program outside of a Cygwin
window.
Running within a Cygwin "window" (Whatever that is) or not is not the
issue.
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.
Even when TMPDIR is set in Windows syntax as C:\tmp, on startup
Perl transmogrifies it to /tmp (or whatever, per cygpath -u).
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
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".
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".
However many Windows programs understand the syntax of C:/foo/bar
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.
The definition of "writable" differs between the POSIX world and the
Windows world.
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@xxxxxxxxx
.
- Follow-Ups:
- Re: Cygwin or Windows: file permission functions are broken
- From: Andrew DeFaria
- Re: Cygwin or Windows: file permission functions are broken
- References:
- Cygwin or Windows: file permission functions are broken
- From: Tim McDaniel
- Re: Cygwin or Windows: file permission functions are broken
- From: Andrew DeFaria
- Cygwin or Windows: file permission functions are broken
- Prev by Date: Re: Circular lists
- Next by Date: Re: fastest way to allocate memory ?
- Previous by thread: Re: Cygwin or Windows: file permission functions are broken
- Next by thread: Re: Cygwin or Windows: file permission functions are broken
- Index(es):
Relevant Pages
|
