Issue: Why does manicopy() mess with file permissions?
I replicataed Iain's problem by setting an odd umask of 0077. His message
didn't go to the list so I'll sum up. I recently added a test to make sure
manicopy() is faithfully honoring the permissions of the original files.
Turns out under certain conditions it wasn't.
manicopy() works two ways. If hard links are available it will hard link
the file. Otherwise it will copy the file. The two methods had different
semantics for preserving the permissions so if you were on a system
without hard links you'd get a read-only distribution. I unified their
chmod logic so this is no longer the case.
I threw in a test to see if manicopy() faithfully preserves the original
permissions. It quite deliberately doesn't. The logic looks like
this:
my $perm = 0444 | (stat $file)[2] & 0700;
chmod( $perm | ( $perm & 0100 ? 0111 : 0 ), $file );
What that boils down to is...
1) Strip off all group and world permissions (stat $file)[2] & 0700
2) Make everyone able to read it
3) If the owner can execute it, allow everyone to execute it
Only #2 really makes sense to me.
Worse, in the case where hard links are involved, the chmod applies to
both the distdir "copy" and the original file. "make distdir" can
alter the permissions of the original files! For example, a file set
0777 will have its group and world writable permissions stripped off to
become 0755.
I'm really not fond of MakeMaker screwing around with permissions like
this. Having different permissions in the distdir than the original is the
sort of "helpful" behavior that's just going to get in someone's way.
Changing the original permissions is even worse. However, its been doing
this for such a long time that I might just leave it be until I get a
real complaint.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/
It's Absinthe time!
