The rmdir should be successful just as removing /sbin/init would be.
The directory should actually dissappear when you change out of it.
The problem I guess is that directories are nested and you could get
many pending rmdir actions. Then there is the problem of adding files
to a directory with a pending rmdir. You could let a rmdir of a directory
happen even with files present, in which case the directory exists
until all files are deleted and no process is in the directory. Then
you get the odd result:
mkdir testdir
touch testdir/somefile
rmdir testdir
cd testdir
rm somefile
cd .. # directory dissapears
I almost like it. Would it conflict with some standard?
> Lets' say I have a server. The server creates a directory for each job.
> When the job is finished, the directory is deleted.
>
> This works perfectly, except (with a directory-locking scheme) when there's
> somebody else in the same directory. Like the network backup process. Or my
> shell, when I want to check up on the job's process.
>
> Right now, the server deletes the directory, and the backup process sees
> it's empty and moves on to other things. I can do the same with my shell.
> (Not being able to call getwd() successfully isn't a problem, that happens
> very often, eg. when the parent directory is unreadable.)
>
> With locking, the directory will be undeletable and it'll sit around forever.
Only if rmdir does not wait around like rm (unlink?) would.