Prev: FAQ 1.10 Can I do [task] in Perl?
Next: close STDERR considered puzzling
From: PerlFAQ Server on 5 Jul 2010 06:00
This is an excerpt from the latest version perlfaq5.pod, which
comes with the standard Perl distribution. These postings aim to
reduce the number of repeated questions as well as allow the community
to review and update the answers. The latest version of the complete
perlfaq is at http://faq.perl.org .

--------------------------------------------------------------------

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.



--------------------------------------------------------------------

The perlfaq-workers, a group of volunteers, maintain the perlfaq. They
are not necessarily experts in every domain where Perl might show up,
so please include as much information as possible and relevant in any
corrections. The perlfaq-workers also don't have access to every
operating system or platform, so please include relevant details for
corrections to examples that do not work on particular platforms.
Working code is greatly appreciated.

If you'd like to help maintain the perlfaq, see the details in
perlfaq.pod.
From: Ilya Zakharevich on 5 Jul 2010 16:43
On 2010-07-05, Peter J. Holzer <hjp-usenet2(a)hjp.at> wrote:
> 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).

Does POSIX specify behaviour of filesystems at all?

Thanks,
Ilya
From: Ben Morrow on 5 Jul 2010 16:58

Quoth Ilya Zakharevich <nospam-abuse(a)ilyaz.org>:
> On 2010-07-05, Peter J. Holzer <hjp-usenet2(a)hjp.at> wrote:
> > 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).
>
> 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.

No mention of the permissions of the file itself, though POSIX does
permit systems to define 'additional access control mechanisms' which
further restrict the access permissions. Conceivably one of these could
forbid unlinking a read-only file.

Ben

From: Ilya Zakharevich on 6 Jul 2010 18:23
On 2010-07-05, Ben Morrow <ben(a)morrow.me.uk> wrote:
>
> Quoth Ilya Zakharevich <nospam-abuse(a)ilyaz.org>:
>> On 2010-07-05, Peter J. Holzer <hjp-usenet2(a)hjp.at> wrote:
>> > 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).
>>
>> 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"

(As in: HOLYFS is not POSIX-confirming on RH version < 23.2 ;-)

Yours,
Ilya
From: Ilya Zakharevich on 7 Jul 2010 18:41
On 2010-07-07, Peter J. Holzer <hjp-usenet2(a)hjp.at> wrote:
> 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.

OK, lemme try to split this hair more precisely now. For me,
"properties of filesystem" is what is preserved when you carry a
DASD=disk to another computer (or boot to another OS).

Thanks for the nice discussion of details,
Ilya
 | 
Pages: 1
Prev: FAQ 1.10 Can I do [task] in Perl?
Next: close STDERR considered puzzling