Re: `rmdir .` doesn't work in 2.4

Re: `rmdir .` doesn't work in 2.4

[Andries.Brouwer]

    From: Andrea Arcangeli <andrea@suse.de>

    > But in fact it fails with EINVAL, and
    > 
    > [EINVAL]: The path argument contains a last component that is dot.

    I can't confirm. The specs I'm checking are here:

        http://www.opengroup.org/onlinepubs/007908799/xsh/rmdir.html

That is the SUSv2 text, one of the ingredients for the new
POSIX standard. I quoted the current Austin draft, the current
draft for the next version of the POSIX standard.

Quoting a text fragment:

        The rmdir( ) function shall remove a directory whose name is given by
        path. The directory is removed only if it is an empty directory.
        If the directory is the root directory or the current working
        directory of any process, it is unspecified whether the function
        succeeds, or whether it shall fail and set errno to [EBUSY].
        If path names a symbolic link, then rmdir( ) shall fail and
        set errno to [ENOTDIR]. If the path argument refers to a path
        whose final component is either dot or dot-dot, rmdir( ) shall
        fail. ...


    > Indeed, rmdir("P/D") does roughly the following:
    > (i) check that P/D is a directory
    > (ii) check that P/D does not have entries other than . and ..
    > (iii) delete the names . and .. from P/D
    > (iv) delete the name D from P

    SUSv2 is straightforward. It doesn't talk about (iv).

I just made explicit what rmdir() actually does, in order to
show that a trailing dot really is a different case where
other rules than the usual ones would have to be applied.
Indeed, rmdir("foo/bar") finishes by removing the name "bar"
from the directory "foo", but rmdir("foo/.") does not finish
by removing the name "." from the directory "foo".

Andries


[Think classical Unix: there are inodes, and there are names.
The rmdir call, just like rm, removes names. Now foo and foo/.
may both be names for the same inode, but they are not the same name.]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Andrea Arcangeli]

On Mon, Jan 08, 2001 at 11:50:44PM +0100, Andries.Brouwer@cwi.nl wrote:
>     From: Andrea Arcangeli <andrea@suse.de>
> 
>     > But in fact it fails with EINVAL, and
>     > 
>     > [EINVAL]: The path argument contains a last component that is dot.
> 
>     I can't confirm. The specs I'm checking are here:
> 
>         http://www.opengroup.org/onlinepubs/007908799/xsh/rmdir.html
> 
> That is the SUSv2 text, one of the ingredients for the new
> POSIX standard. I quoted the current Austin draft, the current
> draft for the next version of the POSIX standard.
> 
> Quoting a text fragment:
> 
>         The rmdir( ) function shall remove a directory whose name is given by
>         path. The directory is removed only if it is an empty directory.
>         If the directory is the root directory or the current working
>         directory of any process, it is unspecified whether the function
>         succeeds, or whether it shall fail and set errno to [EBUSY].
>         If path names a symbolic link, then rmdir( ) shall fail and
>         set errno to [ENOTDIR]. If the path argument refers to a path
>         whose final component is either dot or dot-dot, rmdir( ) shall
>         fail. ...

I trust your specs said so, however I'm not sure which are the specs
we should follow for Linux.

At least for LFS 2.2.x fixage I always followed the SuSv2 specs and they
doesn't even say that rmdir can return -EINVAL. So returning -EINVAL is wrong
in first place according to SuSv2.

> from the directory "foo", but rmdir("foo/.") does not finish
> by removing the name "." from the directory "foo".

Sure. Also `rmdir .` doesn't mean remove "." from current directory but it
means "remove the directory pointed out by path `.'". The kernel/We definitely
knows which is such directory. That is in sync with the specs: "The rmdir()
function removes a directory whose name is given by path". You agree that the
path "." identifys one directory.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Kurt Roeckx]

On Mon, Jan 08, 2001 at 11:50:44PM +0100, Andries.Brouwer@cwi.nl wrote:
>     From: Andrea Arcangeli <andrea@suse.de>
> 
>     > But in fact it fails with EINVAL, and
>     > 
>     > [EINVAL]: The path argument contains a last component that is dot.
> 
>     I can't confirm. The specs I'm checking are here:
> 
>         http://www.opengroup.org/onlinepubs/007908799/xsh/rmdir.html
> 
> That is the SUSv2 text, one of the ingredients for the new
> POSIX standard. I quoted the current Austin draft, the current
> draft for the next version of the POSIX standard.
> 
> Quoting a text fragment:
> 
>         The rmdir( ) function shall remove a directory whose name is given by
>         path. The directory is removed only if it is an empty directory.
>         If the directory is the root directory or the current working
>         directory of any process, it is unspecified whether the function
>         succeeds, or whether it shall fail and set errno to [EBUSY].
>         If path names a symbolic link, then rmdir( ) shall fail and
>         set errno to [ENOTDIR]. If the path argument refers to a path
>         whose final component is either dot or dot-dot, rmdir( ) shall
>         fail. ...

At the bottom of Andrea Arcangeli's url, it says:
Derived from the POSIX.1-1988 standard.

I think it makes sense that if POSIX changed it, that we should
follow POSIX, and not SuS v2, specially if it simplify's things
in the kernel.


Kurt

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Jesse Pollard]

> On Tue, 9 Jan 2001, Jesse Pollard wrote:
> 
> > Not exactly valid, since a file could be created in that "pinned" directory
> > after the rmdir...
> 
> No, it couldn't (if you can show a testcase when it would - please do, you've
> found a bug). Moreover, busy directories can be removed in 2.4 quite fine -
> it's about pathname, not about the thing being your (or somebody else) pwd.

Apologies to all, foot-in-mouth disease....

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Jesse Pollard]

---------  Received message begins Here  ---------

> 
> Hello Al,
> 
> why `rmdir .` is been deprecated in 2.4.x?  I wrote software that depends on
> `rmdir .` to work (it's local software only for myself so I don't care that it
> may not work on unix) and I'm getting flooded by failing cronjobs since I put
> 2.4.0 on such machine.  `rmdir .` makes perfect sense, the cwd dentry remains
> pinned by me until I `cd ..`, when it gets finally deleted from disk.  I'd like
> if we could resurrect such fine feature (adapting userspace is just a few liner
> but that isn't the point). Comments?

Not exactly valid, since a file could be created in that "pinned" directory
after the rmdir...

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Andrea Arcangeli]

On Tue, Jan 09, 2001 at 07:41:21AM -0600, Jesse Pollard wrote:
> Not exactly valid, since a file could be created in that "pinned" directory
> after the rmdir...

In 2.2.x no file can be created in the pinned directory after the rmdir.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Stephen C. Tweedie]

Hi,

On Tue, Jan 09, 2001 at 03:06:35PM +0100, Andrea Arcangeli wrote:
> On Tue, Jan 09, 2001 at 07:41:21AM -0600, Jesse Pollard wrote:
> > Not exactly valid, since a file could be created in that "pinned" directory
> > after the rmdir...
> 
> In 2.2.x no file can be created in the pinned directory after the rmdir.

In 2.2, at least some of that protection was in ext2 itself.  POSIX
mandates that a deleted directory has no dirents, so readdir() must
not return even "." or "..".  ext2 achieved this by truncating the dir
to size==0, and by refusing to add dirents to the resulting completely
empty directory.

Do we have enough protection to ensure this for other filesystems?

--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Andrea Arcangeli]

On Wed, Jan 10, 2001 at 02:47:35PM +0000, Stephen C. Tweedie wrote:
> Hi,
> 
> On Tue, Jan 09, 2001 at 03:06:35PM +0100, Andrea Arcangeli wrote:
> > On Tue, Jan 09, 2001 at 07:41:21AM -0600, Jesse Pollard wrote:
> > > Not exactly valid, since a file could be created in that "pinned" directory
> > > after the rmdir...
> > 
> > In 2.2.x no file can be created in the pinned directory after the rmdir.
> 
> In 2.2, at least some of that protection was in ext2 itself.  POSIX
> mandates that a deleted directory has no dirents, so readdir() must
> not return even "." or "..".  ext2 achieved this by truncating the dir
> to size==0, and by refusing to add dirents to the resulting completely
> empty directory.
> 
> Do we have enough protection to ensure this for other filesystems?

Note that this has nothing to do with `rmdir .`. You will run into the
mentioned issue just now with '''rmdir "`pwd`"'''. I've not checked
the other fses but I would put such support into the VFS rather than in ext2
(vfs can do that for you, if you do that the lowlevel fs will never get a
readdir for a delete dentry).

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Alexander Viro]

On Wed, 10 Jan 2001, Andrea Arcangeli wrote:

> > Do we have enough protection to ensure this for other filesystems?
> 
> Note that this has nothing to do with `rmdir .`. You will run into the
> mentioned issue just now with '''rmdir "`pwd`"'''. I've not checked
> the other fses but I would put such support into the VFS rather than in ext2
> (vfs can do that for you, if you do that the lowlevel fs will never get a
> readdir for a delete dentry).

That's precisely what I've already done. grep for IS_DEADDIR() and notice
that it's only checked under ->i_zombie. Both rmdir() and rename() hold
it on victim, readdir() holds it on directory it wants to read and everything
that creates or removes objects holds it on parent. Successful rmdir()
and rename()-over-directory set S_DEAD in the ->i_flags before dropping
->i_zombie.

The only thing that can happen with the dead directory is ->lookup().

IOW, in 2.4 most of filesystems had dropped the -EBUSY on rmdir() they
used to have. And ext2 got rid of the special handling of dead directories -
these checks are done in VFS now. The only fs with special treatment of
rmdir()/rename() wrt busy victims is NFS, IIRC.

Filesystems still can refuse to remove busy directories (same test as in
2.2) but there's almost no reasons for that.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Andrea Arcangeli]

On Wed, Jan 10, 2001 at 12:28:38PM -0500, Alexander Viro wrote:
> That's precisely what I've already done. grep for IS_DEADDIR() and notice

Fine ;)

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Alexander Viro]

On Tue, 9 Jan 2001, Jesse Pollard wrote:

> Not exactly valid, since a file could be created in that "pinned" directory
> after the rmdir...

No, it couldn't (if you can show a testcase when it would - please do, you've
found a bug). Moreover, busy directories can be removed in 2.4 quite fine -
it's about pathname, not about the thing being your (or somebody else) pwd.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Andries.Brouwer]

> I trust your specs said so, however I'm not sure which are the specs
> we should follow for Linux.

> At least for LFS 2.2.x fixage I always followed the SuSv2 specs

We are Linux, and free to do whatever we want.
However, following POSIX makes a large body of software available.
It would be very unwise to deviate from POSIX if it can be avoided.

Now POSIX describes only part of Unix, and for other parts we get
our inspiration from SVID, or X/Open, or SUSv2, or by looking at
what other Unix-like systems do, like *BSD*, Solaris, AIX, etc.
But these sources are often contradictory.

The next version of the POSIX standard (which will simultaneously
be SUSv3) is expected a few months from now. As soon as it exists,
we'll want to follow it, as much as possible. Today it doesnt exist,
but in case of doubt it is reasonable to follow the draft.
(And in case the draft is really ridiculous, there is still time
to file a change request.)

Andries


See http://www.opengroup.org/austin/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Andries.Brouwer]

> why `rmdir .` is been deprecated in 2.4.x?

> `rmdir .` makes perfect sense, the cwd dentry remains pinned

You think that it fails with EBUSY. That would be allowed but not required:

[EBUSY]: The directory to be removed is currently in use by
         the system or some process and the implementation
         considers this to be an error.

Here we are free to consider this "in use" an error or not.
But in fact it fails with EINVAL, and

[EINVAL]: The path argument contains a last component that is dot.

(Quoted from the last Austin draft.)
Thus, for POSIX compliance we do need the current behaviour.

Also logically rmdir(".") is a doubtful operation.
Indeed, rmdir("P/D") does roughly the following:
(i) check that P/D is a directory
(ii) check that P/D does not have entries other than . and ..
(iii) delete the names . and .. from P/D
(iv) delete the name D from P

You see that rmdir("P/.") would have to do something other than (iv),
namely deleting something from the parent directory of P.
In cases where hard links to directories are permitted,
it is not even clear we can talk about "the parent directory".
So, I do not think that "rmdir ." makes perfect sense.

Andries

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Andrea Arcangeli]

On Mon, Jan 08, 2001 at 09:56:18PM +0100, Andries.Brouwer@cwi.nl wrote:
> You think that it fails with EBUSY. That would be allowed but not required:
> 
> [EBUSY]: The directory to be removed is currently in use by
>          the system or some process and the implementation
>          considers this to be an error.
> 
> Here we are free to consider this "in use" an error or not.

I think the above is to allow implementations without something like our dcache
to not be declared "broken" w.r.t. specs.

> But in fact it fails with EINVAL, and
> 
> [EINVAL]: The path argument contains a last component that is dot.

I can't confirm. The specs I'm checking are here:

	http://www.opengroup.org/onlinepubs/007908799/xsh/rmdir.html

They definitely don't say that `rmdir .` must return -EINVAL.

> Indeed, rmdir("P/D") does roughly the following:
> (i) check that P/D is a directory
> (ii) check that P/D does not have entries other than . and ..
> (iii) delete the names . and .. from P/D
> (iv) delete the name D from P

The definition of rmdir according to 2.2.19pre6 and the single unix
specification version 2 is this:

	int rmdir(const char *path);

	DESCRIPTION
		The rmdir() function removes a directory whose name is given by
		path. The directory is removed only if it is an empty
		directory. 

That is strightforward. It doesn't talk about (iv).

> In cases where hard links to directories are permitted,
> it is not even clear we can talk about "the parent directory".

Hardlinks have nothing to do with `rmdir .`. See rmdir . as the equivalent
pointed out by Alexander: "rmdir `pwd`".  `pwd` returns the same thing
regardless the current directory has nlink > 1 or not (even if it has
nlink = 0 infact). The parent directory is still identified as "`pwd`/.." (or
in kernel terms read_lock(current->fs->lock); current->fs->pwd->d_parent).
hardlinks (of files or directories) only matters at the inode level, not at the
dentry level.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Matthias Andree]

On Mon, 08 Jan 2001, Andrea Arcangeli wrote:

> On Mon, Jan 08, 2001 at 09:56:18PM +0100, Andries.Brouwer@cwi.nl wrote:
> Hardlinks have nothing to do with `rmdir .`. See rmdir . as the equivalent
> pointed out by Alexander: "rmdir `pwd`".  `pwd` returns the same thing

You can't delete immutable directories such as . and .. Plus, don't ever
dare to think of interpreting rmdir arguments. Just do what is written.
rmdir . makes no sense. If someone wants rmdir `pwd` he's free to write
just that. Of course, it's ugly because getcwd and the like are kludges,
but you should only delete things you know anyhow.

-- 
Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

`rmdir .` doesn't work in 2.4

[Andrea Arcangeli]

Hello Al,

why `rmdir .` is been deprecated in 2.4.x?  I wrote software that depends on
`rmdir .` to work (it's local software only for myself so I don't care that it
may not work on unix) and I'm getting flooded by failing cronjobs since I put
2.4.0 on such machine.  `rmdir .` makes perfect sense, the cwd dentry remains
pinned by me until I `cd ..`, when it gets finally deleted from disk.  I'd like
if we could resurrect such fine feature (adapting userspace is just a few liner
but that isn't the point). Comments?

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Mohammad A. Haque]

I fail to see why this is useful. you can't do anything in the directory
afterwards.

bash# mkdir foobar
bash# cd foobar/
bash# ls
bash# rmdir .
bash# touch foooooo
touch: foooooo: Operation not permitted
bash# ls

Whats the point of it?

On Mon, 8 Jan 2001, Andrea Arcangeli wrote:

> Hello Al,
>
> why `rmdir .` is been deprecated in 2.4.x?  I wrote software that depends on
> `rmdir .` to work (it's local software only for myself so I don't care that it
> may not work on unix) and I'm getting flooded by failing cronjobs since I put
> 2.4.0 on such machine.  `rmdir .` makes perfect sense, the cwd dentry remains
> pinned by me until I `cd ..`, when it gets finally deleted from disk.  I'd like
> if we could resurrect such fine feature (adapting userspace is just a few liner
> but that isn't the point). Comments?
>
> Andrea
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
>

-- 

=====================================================================
Mohammad A. Haque                              http://www.haque.net/
                                               mhaque@haque.net

  "Alcohol and calculus don't mix.             Project Lead
   Don't drink and derive." --Unknown          http://wm.themes.org/
                                               batmanppc@themes.org
=====================================================================

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Andrea Arcangeli]

On Mon, Jan 08, 2001 at 12:31:29PM -0500, Mohammad A. Haque wrote:
> I fail to see why this is useful. you can't do anything in the directory
> afterwards.
> 
> bash# mkdir foobar
> bash# cd foobar/
> bash# ls
> bash# rmdir .
> bash# touch foooooo
> touch: foooooo: Operation not permitted
> bash# ls
> 
> Whats the point of it?

To type less characters. I'll show you the code that is failing:

def binutils():
	print 'Checking out binutils'
	sys.stdout.flush()
	os.chdir(binutils_dir)
	if os.system('%s update -A -d -P' % CVS):
		print 'failed binutils checkout'
		sys.exit(1)

	print 'Compiling and installing binutils'
	sys.stdout.flush()
	os.chdir('..')
	binutils_build = 'binutils-build-%s' % BUILD
	os.mkdir(binutils_build)
	os.chdir(binutils_build)
	if os.system('../binutils/configure --target=x86_64-unknown-linux --prefix=%s && make && make install' % install_dir):
		print 'failed binutils compile'
		sys.exit(1)
	shutil.rmtree(".")

Why should I write:

	os.chdir("..")
	shutil.rmtree(binutils_build)

when I can simply write:

	shutil.rmtree(".")

I know in the above case I really could avoid the os.chdir(binutils_build) and
to use `cd %s; ...` % (binutils_dir, install_dir) and probably
it wouldn't make much difference, but the above looks simpler and I may have
other things to run while inside the binutils_dir too so it could make lots of
sense to os.chdir there as I just did.

To workaround this misfeature I can simply implement a derivative class of
shutil in my robot and to wrap the rmtree method to emulate the 2.2.x behaviour
in userspace, but I think the old behaviour was more flexible (it was also
showing how much our dcache is powerful) and I still don't see why it's been
removed.  Maybe it was to remove a branch from a fast path? (if so I don't
think it was a good idea, there are many more overhead things that matters more
and that aren't even visible to userspace)

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Alexander Viro]

On Mon, 8 Jan 2001, Andrea Arcangeli wrote:

> in userspace, but I think the old behaviour was more flexible (it was also
> showing how much our dcache is powerful) and I still don't see why it's been
> removed.  Maybe it was to remove a branch from a fast path? (if so I don't
> think it was a good idea, there are many more overhead things that matters more
> and that aren't even visible to userspace)

Racy. Nonportable. Has portable and simple equivalent. Again, don't
bother with chdir at all - if you know the name of directory even
../name will work. It's not about the current directory. It's about
the invalid last component of the name.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Andrea Arcangeli]

On Mon, Jan 08, 2001 at 01:04:24PM -0500, Alexander Viro wrote:
> Racy. Nonportable. Has portable and simple equivalent. Again, don't
> bother with chdir at all - if you know the name of directory even
> ../name will work. It's not about the current directory. It's about
> the invalid last component of the name.

The last component of the name isn't invalid, it's a plain valid directory. If
according to you `rmdir ../name` and rmdir `pwd` makes sense  then according to
me `rmdir .` makes perfect sense too.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Alexander Viro]

On Mon, 8 Jan 2001, Andrea Arcangeli wrote:

> On Mon, Jan 08, 2001 at 01:04:24PM -0500, Alexander Viro wrote:
> > Racy. Nonportable. Has portable and simple equivalent. Again, don't
> > bother with chdir at all - if you know the name of directory even
> > ../name will work. It's not about the current directory. It's about
> > the invalid last component of the name.
> 
> The last component of the name isn't invalid, it's a plain valid directory. If
> according to you `rmdir ../name` and rmdir `pwd` makes sense  then according to
> me `rmdir .` makes perfect sense too.

rmdir() works on _links_, not directories. Just as every other syscall of
that sort. It's _not_ "find directory and kill what you've found", it's
"find a link and destroy it; preserve the fs consistency".

	Code from another posting has a cute little property: it may kill a
directory that has absolutely nothing to your pwd. And that's OK - you
really can't get anything better than "kill whatever my pwd was called"
without a lot of PITA. And yes, it can happen in 2.2, along with many other
fun things.

	Andrea, fix your code. Linux-only stuff is OK when there is no
portable way to achieve the same result. In your situation such way indeed
exists and is prefectly doable in userland. If you want a cute DoWhatIMean
wrapper around rmdir(2) - fine, you've just written one of the variants.
Any reasons to keep that in the kernel? None? Thank you, case closed.

	"My code stopped working on 2.4" should actually be pronouced
"My code wouldn't work on anything but 2.2 (let's ignore the related
races that _are_ in 2.2), so could you please put a fix for my code into
the 2.4? No, I don't want to put that wrapper into my code, put it in 
the kernel". Sorry, not impressed.

	If this wrapper is OK for your purposes (for 99% of situations
it indeed is) - fine, use it. If you really need to destroy the directory
that happens to be your pwd - sorry, no reliable way to do that without
interesting locking. On _any_ UNIX out there. 2.2 included. It will
happily give you -ENOENT and refuse to perform the action above in
case if some other process renames your pwd. Yes, for rmdir(".");
It will also return that if your directory had been already rmdir()'d.
Have fun. Other Unices will return -EINVAL or -EBUSY - depends on
the flavour.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Andrea Arcangeli]

On Mon, Jan 08, 2001 at 04:08:58PM -0500, Alexander Viro wrote:
> 	Andrea, fix your code. Linux-only stuff is OK when there is no

BTW, "rmdir `pwd`" is not portable either.

> portable way to achieve the same result. In your situation such way indeed
> exists and is prefectly doable in userland. If you want a cute DoWhatIMean
> wrapper around rmdir(2) - fine, you've just written one of the variants.

As just said I'm really not concerned about my code.

> Any reasons to keep that in the kernel? None? Thank you, case closed.

I think it would provide nicer semantics as 2.2.x does.  The performance
argument seems irrelevant to me.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Linus Torvalds]

In article <20010108225605.Y27646@athlon.random>,
Andrea Arcangeli  <andrea@suse.de> wrote:
>On Mon, Jan 08, 2001 at 04:08:58PM -0500, Alexander Viro wrote:
>> 	Andrea, fix your code. Linux-only stuff is OK when there is no
>
>BTW, "rmdir `pwd`" is not portable either.

Indeed. Avoid it if you can.

But at least "rmdir `pwd`" is not _required_ to fail, like rmdir("."/"..").

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Stefan Traby]

On Mon, Jan 08, 2001 at 03:28:29PM -0800, Linus Torvalds wrote:

> But at least "rmdir `pwd`" is not _required_ to fail, like rmdir("."/"..").

"rmdir `pwd`" is required to fail (at least under csh, bash, ksh) if the
path component contains a white space and thereof it can't be a valid
replacement for Andreas "rmdir ." which was what Al initially suggested.

Yes, I'm very pickey about that; but hey, I don't want to force anyone
to write GNU/Linux like rms; just valid shell code. :)

I hope you now agree that "rmdir `pwd`" makes not much sense - except in
bug reports for bash, csh and ksh scripts or in scripts dedicated to
the Win32 environment :)

-- 

  ciao - 
    Stefan

" Lession 1: Quoting.                   Lession 2: Power up the machine. "
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Eric Lammerts]

On Tue, 9 Jan 2001, Stefan Traby wrote:
> "rmdir `pwd`" is required to fail (at least under csh, bash, ksh) if the
> path component contains a white space and thereof it can't be a valid
> replacement for Andreas "rmdir ." which was what Al initially suggested.
>
> Yes, I'm very pickey about that; but hey, I don't want to force anyone
> to write GNU/Linux like rms; just valid shell code. :)

Of course you should do rmdir "`pwd`"
But this is a userspace issue.

Eric

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Albert D. Cahalan]

Alexander Viro writes:

> [...] If you really need to destroy the directory
> that happens to be your pwd - sorry, no reliable way to do that without
> interesting locking. On _any_ UNIX out there. 2.2 included. It will
> happily give you -ENOENT and refuse to perform the action above in
> case if some other process renames your pwd. Yes, for rmdir(".");

Well, this bites.

Locking guess: use a global read-write lock, with the "write" case
being deletion of "." and the "read" case being everything else.
You could have one lock per CPU, with the writer needing to grab all
of them in order. So removal of "." pays the cost.

If the standards gripe, well, rmdot() is a nice name.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Alexander Viro]

On Tue, 9 Jan 2001, Albert D. Cahalan wrote:

> Alexander Viro writes:
> 
> > [...] If you really need to destroy the directory
> > that happens to be your pwd - sorry, no reliable way to do that without
> > interesting locking. On _any_ UNIX out there. 2.2 included. It will
> > happily give you -ENOENT and refuse to perform the action above in
> > case if some other process renames your pwd. Yes, for rmdir(".");
> 
> Well, this bites.
> 
> Locking guess: use a global read-write lock, with the "write" case
> being deletion of "." and the "read" case being everything else.
> You could have one lock per CPU, with the writer needing to grab all
> of them in order. So removal of "." pays the cost.

It's _so_ far from the SMP cache issues that it's not even funny. So reference
to brw-locks is completely bogus. What you are proposing is to serialize
rmdir() and rename() (including lookups) wrt rmdir and rename. Globally.
Fun, fun...
 
> If the standards gripe, well, rmdot() is a nice name.

If anything, frmdir() might be a better name. However, it's really
inconsistent with the whole namespace-modifying stuff. You don't have
flink(fd, newname). frename() and funlink() are not even funny - _which_
link would you want to be renamed/removed?

Filesystem consists of two types of objects - files (and that includes
directories, etc.) and links. Pathname can be evaluated to link and to
file. Namespace syscalls (creat()/mkdir()/mknod()/symlink()/link()/
unlink()/rmdir()/rename()) operate on links. open(), truncate(), stat(),
lstat(), etc. operate on files - completely different can of worms.

2.2 tried (without success) to make rmdir() and some cases of rename() act
on files. Notice that if you have /foo as pwd, "." and "/foo" will evaluate
to the same file, but to different links. That's what it's really about.

We could add new syscalls. However, I'm yet to see the real-world situation
where they would be needed enough to warrant their inclusion. And I mean
real-world, not an exercise asking for that functionality. Occam's Razor...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Albert D. Cahalan]

Alexander Viro writes:
> On Tue, 9 Jan 2001, Albert D. Cahalan wrote:
>> Alexander Viro writes:
>>
>>> [...] If you really need to destroy the directory
>>> that happens to be your pwd - sorry, no reliable way to do that without
>>> interesting locking. On _any_ UNIX out there. 2.2 included. It will
>>> happily give you -ENOENT and refuse to perform the action above in
>>> case if some other process renames your pwd. Yes, for rmdir(".");
>>
>> Well, this bites.
>>
>> Locking guess: use a global read-write lock, with the "write" case
>> being deletion of "." and the "read" case being everything else.
>> You could have one lock per CPU, with the writer needing to grab all
>> of them in order. So removal of "." pays the cost.
>
> It's _so_ far from the SMP cache issues that it's not even funny.
> So reference to brw-locks is completely bogus. What you are proposing
> is to serialize rmdir() and rename() (including lookups) wrt rmdir
> and rename. Globally. Fun, fun...

As long as nobody tried to remove ".", nothing is serialized.
You can do your lookups in parallel since they can all grab
the read lock at once.

If you prefer some pentuple_down thing though, cool.

>> If the standards gripe, well, rmdot() is a nice name.
>
> If anything, frmdir() might be a better name. However, it's really
> inconsistent with the whole namespace-modifying stuff. You don't
> have flink(fd, newname). frename() and funlink() are not even
> funny - _which_ link would you want to be renamed/removed?

Linux can tell where you got the "f" from in the first place.
Deleted files could cause an error, or turn frename() into flink()
and return success for funlink().

> Filesystem consists of two types of objects - files (and that includes
> directories, etc.) and links. Pathname can be evaluated to link and to
> file. Namespace syscalls (creat()/mkdir()/mknod()/symlink()/link()/
> unlink()/rmdir()/rename()) operate on links. open(), truncate(), stat(),
> lstat(), etc. operate on files - completely different can of worms.
>
> 2.2 tried (without success) to make rmdir() and some cases of rename() act
> on files. Notice that if you have /foo as pwd, "." and "/foo" will evaluate
> to the same file, but to different links. That's what it's really about.

The whole "." and ".." mess is 100% special case to begin with,
so this argument doesn't make sense. The mess already gives
us a link that gets replaced when some other link is renamed,
and two links that get unlinked when something else is unlinked.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Alexander Viro]

On Tue, 9 Jan 2001, Albert D. Cahalan wrote:

> As long as nobody tried to remove ".", nothing is serialized.
> You can do your lookups in parallel since they can all grab
> the read lock at once.

Bzzzert. At which point do you take that lock for rmdir("foo/bar/barf/.")?

> Linux can tell where you got the "f" from in the first place.
> Deleted files could cause an error, or turn frename() into flink()
> and return success for funlink().

For crying out loud, rename() already got a Bastard Semantics From Hell,
choke-full of special cases. Write the complete description of f* behaviour
and let's see what you'll get. Then post it here, OK?

> > 2.2 tried (without success) to make rmdir() and some cases of rename() act
> > on files. Notice that if you have /foo as pwd, "." and "/foo" will evaluate
> > to the same file, but to different links. That's what it's really about.
> 
> The whole "." and ".." mess is 100% special case to begin with,
> so this argument doesn't make sense. The mess already gives
> us a link that gets replaced when some other link is renamed,
> and two links that get unlinked when something else is unlinked.

Side effects. You've got to preserve fs consistency. Operation requested by
caller requires to change the links in (re)moved directory. Which is done.

Again, the main argument is Occam's Razor. I agree that in theory f*()
give things that are not provided by current syscalls. No arguments here.
However, unless you can show the real need to have them in the API they
have no business being there. As an aside, for some filesystems they are
simply impossible - try to implement frmdir() on NFS, for one thing.

The only possible benefit is in atomicity of these guys. _If_ filesystems
can provide it (local ones can do that) _and_ there is a real-world
stuff that needs such atomicity warranties - fine, you've got a case for
inclusion of that stuff. Otherwise presumption of uselessness[1] applies.

[1] Useless until proven useful, aka. Thou Shalt Not Bloat Thy API.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Linus Torvalds]

In article <20010108213036.T27646@athlon.random>,
Andrea Arcangeli  <andrea@suse.de> wrote:
>On Mon, Jan 08, 2001 at 01:04:24PM -0500, Alexander Viro wrote:
>> Racy. Nonportable. Has portable and simple equivalent. Again, don't
>> bother with chdir at all - if you know the name of directory even
>> ../name will work. It's not about the current directory. It's about
>> the invalid last component of the name.
>
>The last component of the name isn't invalid, it's a plain valid directory. If
>according to you `rmdir ../name` and rmdir `pwd` makes sense  then according to
>me `rmdir .` makes perfect sense too.

It makes perfect sense, and Linux used to accept it during the 2.3.x
timeframe.

However, it is against all UNIX standards, and Linux-2.4 will explicitly
not allow it (there's also some parent locking issues there).

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Andrea Arcangeli]

On Mon, Jan 08, 2001 at 03:27:21PM -0800, Linus Torvalds wrote:
> However, it is against all UNIX standards, and Linux-2.4 will explicitly

I may be missing something but apparently SuSv2 allows it, you can check here:

	http://www.opengroup.org/onlinepubs/007908799/xsh/rmdir.html

Infact SuSv2 doesn't even allow rmdir to return -EINVAL.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Stephen C. Tweedie]

Hi,

On Tue, Jan 09, 2001 at 01:01:25AM +0100, Andrea Arcangeli wrote:
> On Mon, Jan 08, 2001 at 03:27:21PM -0800, Linus Torvalds wrote:
> > However, it is against all UNIX standards, and Linux-2.4 will explicitly
> 
> I may be missing something but apparently SuSv2 allows it, you can check here:
> 
> 	http://www.opengroup.org/onlinepubs/007908799/xsh/rmdir.html
> 
> Infact SuSv2 doesn't even allow rmdir to return -EINVAL.

SuS always allows implementations to return other errors than the ones
listed:

  Implementations will not generate a different error number from the
  ones described here for error conditions described in this
  specification, but may generate additional errors unless explicitly
  disallowed for a particular function.

See http://www.opengroup.org/onlinepubs/007908799/xsh/errors.html

--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Alexander Viro]

On Mon, 8 Jan 2001, Andrea Arcangeli wrote:

> Hello Al,
> 
> why `rmdir .` is been deprecated in 2.4.x?  I wrote software that depends on
> `rmdir .` to work (it's local software only for myself so I don't care that it
> may not work on unix) and I'm getting flooded by failing cronjobs since I put
> 2.4.0 on such machine.  `rmdir .` makes perfect sense, the cwd dentry remains
> pinned by me until I `cd ..`, when it gets finally deleted from disk.  I'd like
> if we could resurrect such fine feature (adapting userspace is just a few liner
> but that isn't the point). Comments?

It's a hell of a pain wrt locking. You need to lock the parent, but it can
cease to be your parent while you were locking it. rmdir() (and especially
rename()) are major PITA as is. Adding lock/check/retry everything if
we had been moved was way over the top. Again, rename() was the main
offender, but rmdir() also wasn't nice.

rmdir() and rename() act on links. Yes, for directory there is a special
link - one from the parent and we could try to find it and assume that
caller wanted to do the thing on said link. However, it _is_ overloading
the operation. Adds quite a bit of complexity into the place where we
already have too much. For no good reason, since rmdir(pwd) does the same
thing quite fine, is portable (unlike the rmdir(".") which will fail on
every UNIX except Linux) and does not require special-casing.

All namespace-modifying operation (create/remove/rename) act on the links,
not fs objects. Pathname you are passing identifies the directory entry
that should be affected. Conceptually, actual removal of the inode is a
side effect.

The bottom line: rmdir(".") is gone. Replace it with portable equivalent,
namely
	p = getcwd(pwd, sizeof(pwd));
	if (!p)
		/* handle error - ERANGE or ENOENT */
	rmdir(p);
Shell equivalent is rmdir `pwd`. Also portable.
Same goes for rename(). Notice that _all_ pathes that end on . or .. are
off-limits. Explicit POSIX requirement and in that case I'm 100% agree
with them. Linux used to provide an extension that
	* added complexity (and was handled with races in 2.2)
	* was absolutely nonportable
	* was inconsistent with the semantics of other operations (and
in case of rename() - with other parts of rename() semantics)
	* had simple portable replacement.

He's dead, Jim.

PS: try your code on any other UNIX and see it misbehave.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Andrea Arcangeli]

On Mon, Jan 08, 2001 at 12:58:20PM -0500, Alexander Viro wrote:
> It's a hell of a pain wrt locking. You need to lock the parent, but it can

This is a no-brainer and bad implementation, but shows it's obviously right
wrt locking. (pseudocode, I ignored the uaccess details and all the other not
relevant things)

	sys_rmdir(path)
	{
		char buf[PAGE_SIZE]

		err = sys_getcwd(buf, PAGE_SIZE)
		if (err)
			goto out
		
		if (!memcmp(path, ".", 2))
			path = buf
		err = 2_4_0_sys_rmdir(path)

	out:
		return err
	}

Optimizing things just a little more as _worse_ the overhead of supporting
`rmdir .` can be reduced to a memcmp(name, ".") plus and out of line jump and I
don't see a performance problem with that.

Could you enlight me on where's the locking pain?

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Stephen C. Tweedie]

Hi,

On Mon, Jan 08, 2001 at 09:28:33PM +0100, Andrea Arcangeli wrote:
> On Mon, Jan 08, 2001 at 12:58:20PM -0500, Alexander Viro wrote:
> > It's a hell of a pain wrt locking. You need to lock the parent, but it can
> 
> This is a no-brainer and bad implementation, but shows it's obviously right
> wrt locking. (pseudocode, I ignored the uaccess details and all the other not
> relevant things)
> 
> 		err = sys_getcwd(buf, PAGE_SIZE)
> 		if (!memcmp(path, ".", 2))
> 			path = buf
> 		err = 2_4_0_sys_rmdir(path)

> Could you enlight me on where's the locking pain?

Do the above while another process is renaming one of your parents and
watch an innocent directory get shot down in flames, or prepare for an
incorrect ENOENT.

--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Stefan Traby]

On Mon, Jan 08, 2001 at 12:58:20PM -0500, Alexander Viro wrote:

> Shell equivalent is rmdir `pwd`. Also portable.

Very portable - not.

rmdir "`pwd`" !!!

-- 

  ciao - 
    Stefan

"     ( cd /lib ; ln -s libBrokenLocale-2.2.so libNiedersachsen.so )     "
    
Stefan Traby                Linux/ia32               fax:  +43-3133-6107-9
Mitterlasznitzstr. 13       Linux/alpha            phone:  +43-3133-6107-2
8302 Nestelbach             Linux/sparc       http://www.hello-penguin.com
Austria                                    mailto://st.traby@opengroup.org
Europe                                   mailto://stefan@hello-penguin.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Benson Chow]

Not very portable at all...

hpux = HP/UX 10.2

hpux:~$ mkdir foo
hpux:~$ cd foo
hpux:~/foo$ rmdir "`pwd`"
rmdir: /home/blc/foo: Cannot remove mountable directory
hpux:~/foo$ rmdir .
rmdir: cannot remove .. or .
hpux:~/foo$ rmdir /home/blc/foo
rmdir: /home/blc/foo: Cannot remove mountable directory
hpux:~/foo$ rmdir ./
rmdir: ./: Cannot remove mountable directory
hpux:~/foo$

Maybe HP/UX is messed up as well.

But anyway I'll try to step out of the building that i'm trying to blow
up, regardless of whether or not it will work on a particular OS will
hold onto a floor of it till it's done with it...

-bc

On Mon, 8 Jan 2001, Stefan Traby wrote:

> Date: Mon, 8 Jan 2001 22:54:51 +0100
> From: Stefan Traby <stefan@hello-penguin.com>
> To: Alexander Viro <viro@math.psu.edu>
> Cc: Andrea Arcangeli <andrea@suse.de>, linux-kernel@vger.kernel.org
> Subject: Re: `rmdir .` doesn't work in 2.4
>
> On Mon, Jan 08, 2001 at 12:58:20PM -0500, Alexander Viro wrote:
>
> > Shell equivalent is rmdir `pwd`. Also portable.
>
> Very portable - not.
>
> rmdir "`pwd`" !!!
>
> --
>
>   ciao -
>     Stefan
>
> "     ( cd /lib ; ln -s libBrokenLocale-2.2.so libNiedersachsen.so )     "
>
> Stefan Traby                Linux/ia32               fax:  +43-3133-6107-9
> Mitterlasznitzstr. 13       Linux/alpha            phone:  +43-3133-6107-2
> 8302 Nestelbach             Linux/sparc       http://www.hello-penguin.com
> Austria                                    mailto://st.traby@opengroup.org
> Europe                                   mailto://stefan@hello-penguin.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
>




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Andrea Arcangeli]

On Mon, Jan 08, 2001 at 03:11:08PM -0700, Benson Chow wrote:
> Not very portable at all...
> 
> hpux = HP/UX 10.2
> 
> hpux:~$ mkdir foo
> hpux:~$ cd foo
> hpux:~/foo$ rmdir "`pwd`"
> rmdir: /home/blc/foo: Cannot remove mountable directory
> hpux:~/foo$ rmdir .
> rmdir: cannot remove .. or .
> hpux:~/foo$ rmdir /home/blc/foo
> rmdir: /home/blc/foo: Cannot remove mountable directory
> hpux:~/foo$ rmdir ./
> rmdir: ./: Cannot remove mountable directory
> hpux:~/foo$
> 
> Maybe HP/UX is messed up as well.

It seems not to return -EBUSY. As also mentioned by Andries:

	If the 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]. 

The portable way is the one I mentioned as possible change for my code:

        os.chdir("..")
        shutil.rmtree(binutils_build)

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Wakko Warner]

> Not very portable at all...
> 
> hpux = HP/UX 10.2
> 
> hpux:~$ mkdir foo
> hpux:~$ cd foo
> hpux:~/foo$ rmdir "`pwd`"
> rmdir: /home/blc/foo: Cannot remove mountable directory
> hpux:~/foo$ rmdir .
> rmdir: cannot remove .. or .
> hpux:~/foo$ rmdir /home/blc/foo
> rmdir: /home/blc/foo: Cannot remove mountable directory
> hpux:~/foo$ rmdir ./
> rmdir: ./: Cannot remove mountable directory
> hpux:~/foo$
> 
> Maybe HP/UX is messed up as well.

Nor solaris
[wakko@<removed>:/home/wakko/test] rmdir "`pwd`"
rmdir: /home/wakko/test: Invalid argument
[wakko@<removed>:/home/wakko/test] uname -a
SunOS <removed> 5.8 Generic_108528-03 sun4d sparc SUNW,SPARCcenter-2000
[wakko@<removed>:/home/wakko/test] 


-- 
 Lab tests show that use of micro$oft causes cancer in lab animals
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Andrea Arcangeli]

On Mon, Jan 08, 2001 at 08:37:22PM -0500, Wakko Warner wrote:
> [wakko@<removed>:/home/wakko/test] rmdir "`pwd`"
> rmdir: /home/wakko/test: Invalid argument

Some other OS with a yet different retval? :)

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Marc Lehmann]

On Tue, Jan 09, 2001 at 02:55:15AM +0100, Andrea Arcangeli <andrea@suse.de> wrote:
> > [wakko@<removed>:/home/wakko/test] rmdir "`pwd`"
> > rmdir: /home/wakko/test: Invalid argument
> 
> Some other OS with a yet different retval? :)

It can be much worse (irix-6.5.4):

   bash# mkdir x; cd x; rmdir "`pwd`"
   /x: Can't remove current directory or ..

Here the error message makes sense - but is totally wron in this case :(

And here is linux-2.2.18:

   cerebro:~# mkdir x; cd x;rmdir "`pwd`"
   cerebro:~/x# ls -la
   total 6
   drwxr-x---   0 root     root           35 Jan  9 05:54 .
   drwx------  69 root     root         5372 Jan  9 05:54 ..
   cerebro:~/x# cd
   cerebro:~# ls -la x
   ls: x: No such file or directory

So, no, linux certainly does NOT remove "." ;)

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@opengroup.org |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Bernhard Rosenkraenzer]

On Mon, 8 Jan 2001, Benson Chow wrote:

> Not very portable at all...
>
> hpux = HP/UX 10.2
>
> hpux:~/foo$ rmdir .
> rmdir: cannot remove .. or .

Same on FreeBSD, by the way

bash-2.04# uname -a
FreeBSD freebsd.redhat.de 5.0-20001112-CURRENT FreeBSD 5.0-20001112-CURRENT
#0: Sun Nov 12 14:04:55 GMT 2000 root@usw2.freebsd.org:/usr/src/sys/compile/BERO  i386
bash-2.04# mkdir test
bash-2.04# cd test
bash-2.04# rmdir .
rmdir: .: Invalid argument

LLaP
bero


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Alexander Viro]

On Mon, 8 Jan 2001, Stefan Traby wrote:

> On Mon, Jan 08, 2001 at 12:58:20PM -0500, Alexander Viro wrote:
> 
> > Shell equivalent is rmdir `pwd`. Also portable.
> 
> Very portable - not.
> 
> rmdir "`pwd`" !!!

	OK, got me on that. Yes, you'll need quoting here. Sorry.
Notice that there are two effects in the game:
	* some Unices refuse to rmdir() busy directories. For them
removing the pwd is impossible. Period. You can chdir() away, but
there is no promise that after
chdir foo
chdir ..
foo will refer to the directory that used to be your pwd in the middle.
That's pretty obvious - consider the effect of

chdir foo
chdir ..			mv foo bar
				mv baz foo
So unless you have external information about behaviour of other processes
the only way to pinpoint a directory is to keep it opened/pwd/root. Each
of these will keep it busy and Unices that refuse to rmdir() busy ones
will return -EBUSY on that.
	On such systems there is _no_ reliable way to remove your current
pwd unless you can guarantee that it won't be renamed away by another process.
No matter what you are doing.

	* All Unices are required to refuse rmdir() on pathnames that end on
"." or "..". 2.2 is an exception in that respect - usually it allows such
operation. However, that is _still_ unreliable. rename() called by another
process in the right time will make rmdir(".") return -ENOENT, even though
at any moment "." would resolve to the same directory. Including the window
when rmdir() would fail. Notice that error value is indistinguishable from
the other cases, so blind repeating rmdir(".") while you get -ENOENT is not
a solution (as the matter of fact, it can trivially turn into infinite loop).
	All examples mentioned in that thread (HP/UX, Solaris, *BSD) _will_
fail with "rmdir .". Some of them will fail with "rmdir <your_pwd>" too -
see discussion of -EBUSY above.

	The bottom line: without external information about behaviour of
other processes you can't reliably remove the directory that is your pwd
now. "chdir away and rmdir by the name it used to have" works around the
problem with -EBUSY (on the systems that refuse to remove busy ones) _BUT_
it is still vulnerable to "rename by another process" kind of races.

	If you _have_ such external warranties - trivial wrapper will do
the trick on the systems that allow rmdir() of busy directories and
the same wrapper combined with chdir away will solve the problem for all
systems. There is no reason to put that in the kernel - it will not give
you any additional warranties.

	We _can_ pinpoint the link and do rmdir() on it reliably. We can't
do the same to inode. In principle kernel could do that, but NONE of the
existing Unices (2.2 included) do such things and it would require more
trickery than it's worth.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Pavel Machek]

Hi!

> The bottom line: rmdir(".") is gone. Replace it with portable equivalent,
> namely
> 	p = getcwd(pwd, sizeof(pwd));
> 	if (!p)
> 		/* handle error - ERANGE or ENOENT */
> 	rmdir(p);
> Shell equivalent is rmdir `pwd`. Also portable.

...when you are lucky and all directories up to your path are
readable... Which is not always so. With old glibc, it will fail.
								Pavel
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/