Let me understand this. I have some data that I wish to keep secret, so I set the file so that only I can read it.
I come back the next day and discover that my file is missing because although "they" couldn't read it, they could rename it somewhere else in the file system?
That's logical?
Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
| [reply] |
| [reply] |
I'm not sure whether I agree or disagree. I guess it makes sense if that's what your used to, and there probably isn't too much wrong with it as a way of operating, else it would have changed a long time ago.
That said, Win32 allows any combination of Read|Write|Exec|Delete|Permission|Ownership rights to be applied on a per file or per directory basis, to either individuals or groups, so if AS or whomever built the particular build of Perl choose to more closely emulate the *nix view of permissions, then they certainly could. At least for files managed completely from Perl scripts.
It wouldn't even be that hard to set up a given machine so that the defaults settings followed the User/Group/World pattern. A few clicks on the permissions tab of the roots of the drives, and allow them to propogate would do it. Not so sure I'd want to relinquish that much control, but it could be done.
T'is a shame that the availablity of a point and click Systems Admin utilities means that SA in the Win32 is often seen as something that "anyone can do". This means that many of those charged with doing the task have no real understanding if the why's and wherefores of security, permissions etc. with the knock on effect that the OS gets the blame for the lack of sensible policies and admin on behalf of the sa's (no caps:).
Then again, if MS didn't insist on shipping the OS with the default permissions set so that every damn machine was and open (e-)book...
"the sins of the progenitor shall be visited upon its offspring"!
Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
| [reply] |
It's just a paradigm shift. You are used to separating meta-data from data, but many people aren't. On Windows, they try to keep them together.
For example, this script still has to chase all the meta-data (e.g., chmod, chown) separately. What if there were ACLs? The script needs to be changed yet again to support copying the ACLs. There are downsides to keeping meta-data divorced from data.
--
[ e d @ h a l l e y . c c ]
| [reply] |
Mea Culpa. The Perl rename function seems to happily clobber a read-only file on Windows.
Update. The Perl rename function happily clobbers a read-only file on Win98 family but not on WinNT family! Looking at Perl's win32.c, the reason seems to be that MoveFileEx is used under Windows NT, while on Win98 (where MoveFileEx is not available) it deletes the target file before the rename.
| [reply] |
