GNU bug report logs - #12339
Bug: rm -fr . doesn't dir depth first deletion yet it is documented to do so.

Previous Next

Full log

Message #251 received at 12339 <at> debbugs.gnu.org (full text, mbox):

From: Linda Walsh <coreutils <at> tlinx.org>
To: "12339 <at> debbugs.gnu.org" <12339 <at> debbugs.gnu.org>
Subject: Re: bug#12339: Gnu rm, changed only recently (4-5 years),
	and didn't follow letter of posix...(statement follows)
Date: Wed, 12 Sep 2012 19:49:05 -0700

Eric Blake wrote:
> They are also well-defined terms in the POSIX standard.
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_40
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/basename.html
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/dirname.html
> 
>  Let's look at some different "Cases" of sample pathnames (skipping
>> the easy ones, given the audience):
>>
>> Case A:   "/"     What is the dirname and what is the basename?
>>
>> Answer: <null> and <null>.
> 
> Unfortunately, your interpretation is not consistent with the POSIX
> definitions.  The POSIX-mandated answer is a dirname of '/' and a
> basename of '/'.  Additionally, this particular file name is always a
> directory.
----
	I admit, you are half right.

	It says to return a directory indicator for a basename ... which I find
absurd, however, it says to strip off the '/' for a dirname and only return the 
parent.

Specifically:

The dirname() function shall take a pointer to a character string that contains 
a pathname, and return a pointer to a string that is a pathname of the parent 
directory of that file. Trailing '/' characters in the path are not counted as 
part of the path.

So even if the parent was "/", it is not to count as part of the path.

There is no place on disk or in the the OS that calls the root dir "/", a rootfs 
is mounted
at /, but that's not the name of the rootfs.






> 
>>  Case B: "ENTRY/"     What is the dirname and what is the basename?
>>
>> Answer: Dirname="ENTRY", basename=<null>.  (Explanation seems unnecessary).
> 
> Unfortunately, your interpretation is not consistent with the POSIX
> definitions.  The POSIX-mandated answer is a dirname of '.' 
----

But that is semantically incorrect.  They can define it that way, but semantically
that isn't consistent with existing implementation.


Example:
Is "find" POSIX compatible?   Typing "find DIR", doesn't
yield output of ./dir -- yet that would be required if it followed those rules.


>>  Case C: "ENTRY"    Dir and Basenames?
>>
>> Answer:  it depends on context and what it really is.
> 
> Unfortunately, your interpretation is not consistent with the POSIX
> definitions.  The POSIX-mandated answer is a dirname of '.' and a
> basename of 'ENTRY'.  But you are correct that it may or may not be a
> directory.
---
	yet it is consistent with current implementation and POSIX is meant
to be _descriptive_ not _prescriptive_, therefore it is POSIX that is not matching
implementation.

	People need to read the preamble to POSIX.   If the implementation they have
doesn't match what POSIX describes, then POSIX has err'ed.


>> Whether or not 'ENTRY' is a basename or a dirname depends on whether or
>> not 'ENTRY' is a directory.
> 
> Rather, the POSIX definition states that 'ENTRY' is a basename because
> it is the last non-slash component of the overall string, after
> stripping any trailing slashes.  Remember, a directory is ALSO a file,
----
	It can only be treated as a file when it is empty.  then one can
issue a single command for it's removal.  Otherwise, a directory is more
than just a file.

> just like a symlink or a socket or a character device is also a file.
> The term basename applies to any file, not just non-directory files.
----
	This
> 
>> Example.  In it's default mode rm removes only files.
> 
> Correction - in its default mode, rm removes regular files, symlinks,
> fifos, block devices, character devices, socket files, and any other
> implementation extension file types, but has special case treatment of
> directory files.
-----
	One just said a symlink, socket or char device are files... so what
is being corrected by by the above statement?

AFAIK, I'm I'm differentiating between files entries in a directory and
directory entries  that contain other files.  If the directory
contains nothing and is empty -- it can, 'effectively',  be treated as a file, 
and removed
with it's type-specific-removal operation.

Directories need more than simple unlinking because they are not simply 'entries',
they are objects with references to other objects (including itself).  Those need
special handling to be deconstructed by the OS.  They are not files that the 
user has control
over nor that POSIX should be trying to claim control of.

> this special case treatment is mandated by POSIX, to match historical practice.
---
	Not exactly true.  It's because it is mandated OS function and POSIX is 
descriptive.
(which could be two ways of saying the same thing, but it is not solely for 
historical
benefit).

> 
>> "rm a b c ENTRY d" -- rm expects all entries to to simple basenames.  If
>> it encounters a dirname, it issues an error and refuses to operate on it.
> 
> Correcting your terminology:
> If it encounters a *directory*, it issues an error and refuses to
> operate on it.
---
	If it encounters a 'name' that is a directory name.  That's what
I am calling a dirname -- because that is what it *is*.  It's descriptive
of it's function.

POSIX is suppose to be descriptive. If it is not,  then it is failing.


>> In it's recursive mode, rm will accept basenames and dirnames.  It will
>> inspect each entry to determine if it is a file (basename) or a
>> dir(dirname).


> Again correcting your terminology:

my terminology is accurate.  It doesn't accept directories.  It accepts
NAMES of directories. Don't confuse the name for the object.  We have names
for objects, but the name is not the object.  The directory is a container.
It has a name -- often called a directory name or dirname for short.  But
that's just common sense.  Yet you are saying under POSIX, normal common sense
and literal definitions do not apply.  That's not being descriptive.


> rm will accept directories in addition to other file types.
---
	No, it will accept directory names and handle them separately
and differently from every other entry in a 'dir'.


	

>> Only after the contents have been removed is it no longer a dirpath --
> 
> This statement makes no sense in light of POSIX terminology. 
---
	POSIX is failing at it's job of being descriptive.

	I was careful in choosing my words in writing the previous document,
as they were descriptively taken from their function in the OS.  By using arbitrary,
POSiXELLIAN terminology you start being unable to describe what is and you start
to hinder communication.  This is usually done by authoritarian entities to serve
their own ends.

>> There are 2 entries not covered usually covered by security policies, as
>> they are not discretionary entries -- they are mandatory components of
>> the OS, namely "." and "..".
> 
> Actually, believe it or not, '.' and '..' are NOT mandatory directory
> entries in POSIX.
----

I didn't say it was mandatory in POSIX, just the OS -- that POSIX
isn't following its descriptive mandate is unsurprising.



>> As POSIX is a computer portability standard, one would imagine that they
>> know the difference between dirnames and basenames
> 
> Yes, POSIX has a self-consistent definition of those terms.
----	
      Yes... a self, internally, *Orwellian*, *new-speak* definition.

> No, that is not a consistent statement in light of the POSIX definition
> of the terms.
---
	In which they attempt to obfuscate function and thus, are demonstrably
not following their intended mission of being descriptive.  This brings into
question whether or not they are *really* POSIX terms, or terms created and made
up by opportunists  who see POSIX as a way to create and enforce their standard.
But clearly, they do so by violating POSIX's original charter/mission statement.
Doesn't that mean their statements and words are not POSIX compliant and can't
be considered as POSIX?

	You see, that's where I break with POSIX -- I was all for POSIX compliance
as a descriptive standard... but as soon as they changed from descriptive to
prescriptive, they became 'not-POSIX' anymore.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.