: Indeed. There are good historical reasons why a pathname for any of the
: functions that crated or deleted new files couldn't end with '.' or
: '..'. It just happens that the new Linux dcache doesn't have those
: restrictions which I consider to be a good thing, but with just about
: any other implementation I can think of the supposed POSIX restriction
: actually makes perfect sense.
: Note the "supposed": I've been poring over my POSIX papers, and I wasn't
: actually able to find any place that really forbids 'rmdir(".")' from
: working. So it is entirely possible that the current Linux behaviour is
: actually permissible.
Let me quote:
(ISO/IEC 9945-1, ANSI/IEEE Std 1003.1, Second edition 1996-07-12)
5.5.2.2
The rmdir() function removes a directory whose name is given by path.
The directory shall be removed only if it is an empty directory.
If the named directory is the root directory or the current working
directory of any process, it is unspecified whether the function
succeeds or whether it fails and sets errno to EBUSY.
If the link count of the directory becomes zero and no process has
the directory open, the space occupied by the directory shall be freed
and the directory shall no longer be accessible.
If one or more processes have the directory open when the last link
is removed, the dot and dot-dot entries, if present, are removed
before rmdir() returns and no new entries may be created in the
directory, but the directory is not removed until all references
to the directory have been closed.
Upon successful completion, the rmdir() function shall mark for update
the st_ctime and st_mtime fields of the parent directory.