So .... according to stat(), all directories on my windows Vista box (even those that I can't write to) are drwxrwxrwx.
Does this signify some shortcoming of the stat function on Windows ?
Yes. Windows uses ACLs, not the Unix idea of owning user, group members, and other people (u,g,o). stat() emulates just enough of the Unix idea to allow common programs to work. It pretends that everything is readable and writeable for everyone. Finding out that things may be read-only or even write-only is left to other functions like open, read, and print. If you would run on a Unix system with ACLs, you would have exactly the same situation. The mode information returned by stat does not know about ACLs, and even if stat() tells you a file or directory is readable or writable for everyone, the ACLs may prevent you from reading or writing.
Actually, stat() returns some useful information:
perl -e "printf qq[%08o %s\n],(stat($_))[2],$_ for @ARGV" C:\WINNT C:\
+WINNT\win.ini C:\WINNT\NOTEPAD.EXE c:\WINNT\system32\command.com c:\
+winnt\system32\login.cmd C:\bin\uuencode.pl
00040777 C:\WINNT
00100666 C:\WINNT\win.ini
00100777 C:\WINNT\NOTEPAD.EXE
00100777 c:\WINNT\system32\command.com
00100777 c:\winnt\system32\login.cmd
00100666 C:\bin\uuencode.pl
(Strawberry Perl 5.10.0)
As you see, the directory flag is correct, and the X-bit is only set for directories and executables (determinated by the file extension). So, -f, -d, and -x work as expected.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] [Watch: Dir/Any] [d/l] [select] |
I'm surprised that env_untaint was written that way. 0022 as a umask is 755 permission wise which gives the idea that r and x for group members and everyone else actually works for Windows in a Linux/UNIX way.
Reading stat under perlfunc years ago led me to believe that only a handful of the 13 elements actually worked under Windows. Looking at it now hints that there maybe some cause for doubt - "Not all fields are supported on all filesystem types".
The concept of group and everyone for Windows does work under domains but not directories, which is why stat returns 0777 even on readonly.
Shortcoming of stat - I'd say so, but it's not actually since we're given warning. To get directories that you can't write to I'd use Win32::File so
and not ((stat($_))[2] & 0022)
becomes
and ( $attr & READONLY )
I was going to go through the bitwise & permissions that would yield 0 with 0022, but I actually came on PM to look for something else and now it's home time :p
Just in
P.S. your box is fine
| [reply] [Watch: Dir/Any] [d/l] [select] |
and ( $attr & READONLY )
That doesn't seem to do quite the same thing. GetAttributes() tells me that neither C:/Windows/System32 nor many of the files in it are READONLY. Yet, I can't write to that directory, or to any of the files in it.
Cheers, Rob
| [reply] [Watch: Dir/Any] |
GetAttributes() (from Win32::File) returns the file attributes that were invented around 1980 for MS-DOS, namely ARCHIVE, DIRECTORY, HIDDEN, READONLY, and SYSTEM, plus three new using the remaining bits of a byte, invented somewhere around Windows 98 or NT 4.0: OFFLINE, COMPRESSED, and TEMPORARY. Again, these attributes do not have any relation to the ACLs. Win32::Security::ACL should be able to access the ACLs and to tell you why you can't write to the directory.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] [Watch: Dir/Any] |