> On Mon, Jun 09, 2008 at 03:34:23PM +0200, Aristotle Pagaltzis wrote: > My hope was that there were no effects at all for environments that > don't have permissions bits, but I've no non-Unix environment to test > that, nor any significant experience on non-Unix platforms to make any > predictions, nor was perlport of any help of predicting the behaviour > on non-Unix systems. (My thought was, if the platform doesn't have > permissions, it doesn't really matter what the third argument of sysopen > is). Just about everybody has permission bits, but they do different things with them. It's also filesystem-specific, not necessarily OS-specific. Perl on a Stick may have to worry about these things if those are FAT partitions on the data crystal. That's a good point about perlport -- it ought to cover this better. >> > I don't like the fact that copying from a handle now gives >> > different behavior permissions-wise than copying from a >> > filename, but that inconsistency could be ironed out pretty >> > easily. > > I am surprised about this. My patch takes the permissions bit from the > file handle (either the one passed to copy, or the one after opening > the source file), and there are tests that check whether the permission > bits are set correctly when copying from a file handle. I believe you are correct about what your code does and how your tests verify it. What I'm talking about is the case where your code will be run when copying from a handle and an entirely different code path (basically, the platform-specific syscopy) will be run when not copying from a handle. This heavily patched section of code is where the trouble is: if (defined &syscopy && !$Syscopy_is_copy && !$to_a_handle && !($from_a_handle && $^O eq 'os2' ) # OS/2 cannot handle handles && !($from_a_handle && $^O eq 'mpeix') # and neither can MPE/iX. && !($from_a_handle && $^O eq 'MSWin32') && !($from_a_handle && $^O eq 'MacOS') && !($from_a_handle && $^O eq 'NetWare') ) { [big snip here] return syscopy($from, $copy_to); } This heavily patched section of code almost (but not quite) means that if we're not on Unix, use syscopy for everything because $Syscopy_is_copy is false everywhere except on Unix. But if I'm copying from a handle on any platform not in the list, I'll run your new code instead of syscopy, which means I'll have potentially different behavior than when I'm copying from a filename rather than from a handle. VMS may be the only place where the behavior is likely to have changed, and I could change it back by adding it to the list. But the list has really gotten out of hand, and I wonder what the logic should really be here. In a sense your patch has just added to the list by different means, but rather than making a Unix-oriented syscopy it's made the default copy into the Unix syscopy.Thread Previous | Thread Next