Prev: close STDERR considered puzzling
Next: FAQ 4.65 How can I get the unique keys from two hashes?
From: Peter J. Holzer on 5 Jul 2010 09:41
On 2010-07-05 10:00, PerlFAQ Server <brian(a)theperlreview.com> wrote:
> 5.38: Why does Perl let me delete read-only files? Why does "-i" clobber protected files? Isn't this a bug in Perl?
>
> This is elaborately and painstakingly described in the file-dir-perms
> article in the "Far More Than You Ever Wanted To Know" collection in
> http://www.cpan.org/misc/olddoc/FMTEYEWTK.tgz .
>
> The executive summary: learn how your filesystem works. The permissions
> on a file say what can happen to the data in that file. The permissions
> on a directory say what can happen to the list of files in that
> directory. If you delete a file, you're removing its name from the
> directory (so the operation depends on the permissions of the directory,
> not of the file). If you try to write to the file, the permissions of
> the file govern whether you're allowed to.
>

This answer is Unix-centric. AFAIK on Windows the permissions on the
file are also considered, plus a few other circumstances (file open,
locked, ...). So while I very much endorse the first sentence "learn how
your filesystem works", I would qualify the rest with "On Unix systems
...." or maybe "On POSIX-conforming file systems ..." (Frankly, I don't
know how NTFS on Linux or ext3 on Windows behave). Plus a sentence like
"On other systems the situation may be different." at the end. An
explanation how it works on Windows would be even better but I'm not
qualified to write that.

hp

From: Peter J. Holzer on 7 Jul 2010 07:23
On 2010-07-06 22:23, Ilya Zakharevich <nospam-abuse(a)ilyaz.org> wrote:
> On 2010-07-05, Ben Morrow <ben(a)morrow.me.uk> wrote:
>> Quoth Ilya Zakharevich <nospam-abuse(a)ilyaz.org>:
>>> Does POSIX specify behaviour of filesystems at all?
>>
>> From SUSv3:
>>
>> The unlink() function shall fail and shall not unlink the file if:
>>
>> [EACCES]
>> Search permission is denied for a component of the path prefix,
>> or write permission is denied on the directory containing the
>> directory entry to be removed.
>
> That's properties of an API call, not filesystem behaviour. It may be
> implemented in CRTL... So it would be
>
> "On POSIX-conforming CRTL"
>
> not
>
> "On POSIX-conforming file systems"

POSIX cares only about the behaviour of the unlink call, not the
implementation. However, on most systems at least part of the
implementation is filesystem specific and it has been common for Unix
systems to provide both filesystems with POSIX semantics (UFS, FFS, ...)
and without (full) POSIX semantics (NFS, ...). So you could never say
"the unlink function on HP-UX 8.0 is POSIX-conforming", you could only
say "the unlink function of HP-UX 8.0 on a UFS file system with default
options is POSIX conforming, but the unlink function of HP-UX 8.0 on an
NFS file system is not". So it makes sense to view this as a property of
the file system code, not the OS as a whole. On modern systems this is
even more pronounced because they support more file systems.

hp

 | 
Pages: 1
Prev: close STDERR considered puzzling
Next: FAQ 4.65 How can I get the unique keys from two hashes?