Front page | perl.perl5.porters |
Postings from April 2014
Re: -l on win32, VMS etc Was: [perl #72028] execute permissionmissing from some utils
Thread Previous
From:
Steve Hay
Date:
April 6, 2014 18:23
Subject:
Re: -l on win32, VMS etc Was: [perl #72028] execute permissionmissing from some utils
Message ID:
CADED=K5jWRyquLxH3+RFLx7yfjL_kMEZUN+nPB0X3xv=jSDkGg@mail.gmail.com
On 6 April 2014 13:37, Dave Mitchell <davem@iabyn.com> wrote:
> On Sat, Mar 29, 2014 at 08:18:47PM +0000, Zefram wrote:
>> I'd be inclined to make the chmod conditional on $^O =~
>> /\A(?:MSWin32|VMS)\z/. If that breaks it for some OS of which we
>> know even less, presumably we'll get a bug report identifying the OS.
>> Flawed though this approach is, by fixing the module for all Unices we'd
>> immediately make it qualitatively much less buggy.
>
> I've now pushed something similar as smoke-me/davem/ext-install.
>
> I'd be particularly keen for owners of non-POSIX platforms to check it by
> installing an older version of a CPAN module, then installing a newer
> version and making sure that it deletes the older files and replaces
> them with newer ones.
>
It works fine for me in normal usage on Windows -- as I'd expect,
since you've not actually changed anything for Windows users.
Hard links, soft links ("junctions") and symbolic links are all
possible on Windows (7, at least), e.g. see
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365006%28v=vs.85%29.aspx
I tried following Zefram's minimal demonstration from #72028 (noting
that the 'link' and 'target' arguments in Windows 7's mklink command
are the opposite way around to *nix's ln command:
http://technet.microsoft.com/en-us/library/cc753194.aspx), only to
find that ExtUtils::Install fails to install the from/a file at all,
claiming that some unnamed file doesn't exist!:
C:\Dev\Temp>mkdir from to
C:\Dev\Temp>echo oldoldold >to\b
C:\Dev\Temp>perl -e "chmod 0755, 'to/b'"
C:\Dev\Temp>mklink to\a to\b
symbolic link created for to\a <<===>> to\b
C:\Dev\Temp>echo new >from\a
C:\Dev\Temp>perl -e "chmod 0755, 'from/a'"
C:\Dev\Temp>dir to
Volume in drive C is OS
Volume Serial Number is 4E13-1B46
Directory of C:\Dev\Temp\to
06/04/2014 19:07 <DIR> .
06/04/2014 19:07 <DIR> ..
06/04/2014 19:07 <SYMLINK> a [to\b]
06/04/2014 19:06 12 b
2 File(s) 12 bytes
2 Dir(s) 1,286,697,168,896 bytes free
C:\Dev\Temp>C:\Dev\Software\Cygwin\bin\ls -l to
total 1
lrwxrwxrwx 1 Administrators None 4 Apr 6 19:07 a -> to/b
-rwx------+ 1 Administrators None 12 Apr 6 19:06 b
C:\Dev\Temp>perl -le "printf '0%o', 07777 & (stat 'to/a')[2]"
00
C:\Dev\Temp>perl -le "printf '0%o', 07777 & (stat 'to/b')[2]"
0666
C:\Dev\Temp>perl -MExtUtils::Install -e "install({ 'from' => 'to' })"
Installing to\a
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
ERROR: Cannot copy 'from\a' to 'to\a': No such file or directory
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
at -e line 1.
The file from\a does exist, and is readable and not empty, so I can
only assume that it's complaining about some problem with the target
file, to\a -- because it's a symbolic link?
And indeed if I replace "mklink to\a to\b" with "copy to\b to\a" above
then the install works fine.
It also works with a hard link, but the chmod 0666 seems not to have
followed the link like it does on *nix -- the link target (to\b) has
the same (wacky!) perms as before the installation; only the installed
file (to\a) is different:
C:\Dev\Temp>mkdir from to
C:\Dev\Temp>echo oldoldold >to\b
C:\Dev\Temp>perl -e "chmod 0755, 'to/b'"
C:\Dev\Temp>mklink /h to\a to\b
Hardlink created for to\a <<===>> to\b
C:\Dev\Temp>echo new >from\a
C:\Dev\Temp>perl -e "chmod 0755, 'from/a'"
C:\Dev\Temp>dir to
Volume in drive C is OS
Volume Serial Number is 4E13-1B46
Directory of C:\Dev\Temp\to
06/04/2014 19:13 <DIR> .
06/04/2014 19:13 <DIR> ..
06/04/2014 19:13 12 a
06/04/2014 19:13 12 b
2 File(s) 24 bytes
2 Dir(s) 1,286,697,095,168 bytes free
C:\Dev\Temp>C:\Dev\Software\Cygwin\bin\ls -l to
total 2
-rwx------+ 2 Administrators None 12 Apr 6 19:13 a
-rwx------+ 2 Administrators None 12 Apr 6 19:13 b
C:\Dev\Temp>perl -le "printf '0%o', 07777 & (stat 'to/a')[2]"
0666
C:\Dev\Temp>perl -le "printf '0%o', 07777 & (stat 'to/b')[2]"
0666
C:\Dev\Temp>perl -MExtUtils::Install -e "install({ 'from' => 'to' })"
Installing to\a
C:\Dev\Temp>dir to
Volume in drive C is OS
Volume Serial Number is 4E13-1B46
Directory of C:\Dev\Temp\to
06/04/2014 19:15 <DIR> .
06/04/2014 19:15 <DIR> ..
06/04/2014 19:13 6 a
06/04/2014 19:13 12 b
2 File(s) 18 bytes
2 Dir(s) 1,286,697,074,688 bytes free
C:\Dev\Temp>C:\Dev\Software\Cygwin\bin\ls -l to
total 2
-r-x------+ 1 Administrators None 6 Apr 6 19:13 a
-rwx------+ 1 Administrators None 12 Apr 6 19:13 b
C:\Dev\Temp>perl -le "printf '0%o', 07777 & (stat 'to/a')[2]"
0444
C:\Dev\Temp>perl -le "printf '0%o', 07777 & (stat 'to/b')[2]"
0666
I think this demonstrates that nobody is using symbolic links like
this on Windows since ExtUtils::Install fails in that case anyway; and
if anyone is using hard links (also quite unlikely, I think) then it
seems to work fine anyway.
I don't think the chmod is necessary, btw, but since it doesn't hurt
like it does on *nix I'd be inclined to not change it in case there is
some reason for it that I'm not aware of. A read-only file (in the
sense of the read-only file 'attribute', which is what chmod 0666 ...
will turn off) can be deleted by perl's unlink() anyway, although
Windows's own del command can't delete it!:
C:\Dev\Temp>echo junk>a
C:\Dev\Temp>perl -le "printf '0%o', 07777 & (stat 'a')[2]"
0666
C:\Dev\Temp>attrib a
A C:\Dev\Temp\a
C:\Dev\Temp>attrib +r a
C:\Dev\Temp>perl -le "printf '0%o', 07777 & (stat 'a')[2]"
0444
C:\Dev\Temp>attrib a
A R C:\Dev\Temp\a
C:\Dev\Temp>del a
C:\Dev\Temp\a
Access is denied.
C:\Dev\Temp>perl -e "unlink 'a' or die $!"
C:\Dev\Temp>dir /b a
File Not Found
unlink() won't be able to delete a file that has been made read-only
via ACLs (access control lists), and chmod 0666 ... won't help there
either, but it won't hurt, and again people can't be working that way
anyway.
So your (no-op) change on Windows is fine with me.
Thread Previous