* Craig A. Berry <craig.a.berry@gmail.com> [2008-05-23 17:55]: > On VMS, and I believe also on Win32 (which closely mimics the > VMS file protection scheme), the absence of a relationship > between the source file permissions and the target file > permissions is by design. The specifics can get rather > complicated, but the gist of it is that a copy of a file is a > new file that is expected to play nice in its new environment, > where "environment" may include previous versions of the same > file, process defaults, directory defaults, ACLs, etc. Native > utilities can override this behavior (COPY/PROTECTION on VMS, > XCOPY /O on Windows), but it's something you have to ask for > explicitly. Well, on Unix, there is at least one bit of metadata that files are pretty much expected to *always* carry along unless the user explicitly requests otherwise, which is the executable bit. On Win32, this issue doesn’t come up, because it uses the filename to decide whether a file is an executable. I don’t know what VMS does, but I assume that it’s similar to Win32 in this regard. So if the file copy routine does not preserve permission bits on Win32 and VMS, the user needn’t care too much as they still have control over the most important property of the file. As for permission bits, both Win32 and VMS have a more complex permission system, and in particular at least Win32 has a concept of permissions inherited from directories to the files therein. Unix itself does not (although individual filesystems may, and depending on flavour of Unix/Linux there may be filesystem- independent ACL layer as well), so there is an expectation that a file carry its Unix model permission bits along (even if there is an ACL layer). (And if there is, there is no way for applications to copy those along in a ACL-layer-agnostic way, which is, I wager, the original motivation for File::Copy to punt entirely.) Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>Thread Previous | Thread Next