Dave Mitchell wrote: >But thinking a little further, it makes no sense (on UNIXy systems at >least) to do the chmod before unlinking a file, since it's the permissions >of the directory, not the file, that determine whether a file can be >unlinked. Indeed. I'm pretty annoyed that correctness on Unix has become a casualty of the quest for portability to crippled OSes. >So I guess the chmod 066 is only for Windows etc? I believe on Windows permission to delete a file is the same as permission to write to that file. The chmod would make sense in that context. On VMS, permission to delete a file is a separate permission bit, stored on the file itself. I don't know what the chmod emulation does with it. Quite likely it sets the delete-permission bit to match the write-permission bit. >I think I'm a bit out of my depth on such portability issues, What we need is a way to determine whether the chmod is needed. $^O is probably sufficient key, if we can just be sure which values indicate an OS that needs it. Digging in the git history and BackPAN, the chmod logic came in while EU:I was bundled in the MakeMaker distro, in MakeMaker-5.27. The Changes entry describing it credits it to Ilya. It doesn't say specifically what OSes it's intended for. 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. -zeframThread Previous | Thread Next