Linux: How could a directory be created without "." and ".."?

Question

I am not sure if the following issue is specific to busybox: I have an embedded device with busybox installed. From what I understand, when a directory is created, usually 2 hidden files will be automatically created: . to represent the current directory and .. to represent the parent directory. For example, by typing mkdir -p /tmp/normal_dir; cd /tmp/normal_dir; ls -a, the output will be . ...

However, I have seen a case where an existing directory (/tmp/strange_dir) does not show . and ... That is, by typing cd /tmp/strange_dir; ls -a, the output is empty, although navigating to the parent directory still works. That is, by typing cd .., the content is correct.

My question is: How could such a directory without . and .. (like /tmp/strange_dir) be created? I am puzzled.

Answer 1

This can happen if you are accessing the directory via a symlink, but the linked directory is removed. For example, in /tmp, let's create a directory and a symlink to that directory:

$ cd /tmp
$ mkdir normal_dir
$ ln -s normal_dir strange_dir

Now, if we navigate to strange_dir, we get the expected output:

$ cd strange_dir
$ ls -a
. ..

If, however, we remove the directory normal_dir without changing the directory, indeed we get an interesting result:

$ rmdir /tmp/normal_dir
$ ls -a

$ ls -al
total 0

So although our link now points to nothing, the working "directory" of the shell is still the same:

$ pwd
/tmp/strange_dir

$ cd /tmp/strange_dir
bash: cd: /tmp/strange_dir: No such file or directory

$ ls -al
total 0

Running stat -L . while our working directory is still at /tmp/strange_dir will now show Size: 0 as discussed in the above comments. Although the output of ls shows nothing now (not even . nor ..), we can still navigate just fine to the parent directory .. in this case, as you outlined:

$ cd ..
$ pwd
/tmp

$ ls -a
. .. strange_dir

Although the symlink still exists, it doesn't point to anything, so we can't cd back into strange_dir at this point, unless the directory /tmp/normal_dir is re-created. To clean up, we can just remove the symlink by calling rm /tmp/strange_dir.

Answer 2

It's conceivable that such an aberration could be created if somebody said

mkdir /tmp/strange_dir

at a time when the filesystem was full (i.e., there were no free blocks).  It would still (probably) have been possible to create the strange_dir directory entry in /tmp, because that would require only a few bytes of unused space in one of the blocks already allocated to /tmp.  But it would have been impossible to allocate a block for strange_dir itself, and therefore it would have been impossible to create the . and .. entries.  In such a case, I would expect the mkdir program to remove (unlink) the strange_dir directory entry in /tmp, but software doesn't always do what I expect.

Other possibilities:

• mkdir got interrupted (terminated) between creating the strange_dir directory entry in /tmp and creating the . and .. entries in strange_dir.  I would expect mkdir to catch the interrupt signal (i.e., Ctrl+C) and clean up after itself, but see above regarding software and my expectations of it.  And, of course, it cannot catch the kill signal or a system crash. 
• rmdir got interrupted (terminated) between unlinking the . and .. entries in strange_dir and unlinking the strange_dir directory entry in /tmp.

One might expect that the fsck that runs after a crash would detect the strange_dir and do something about it, but ....

Yes, of course, if a directory has a size of 0, that means that it has no blocks allocated to it, and therefore it cannot have any contents (not even little ones like . and ..).

I don't fully understand why cd .. would work when there is no .., but see the discussion in Removing a directory from inside using the command line interface.  It turns out that

mkdir /tmp/strange_dir
cd /tmp/strange_dir
ls -lai                 ← Shows normal . and .., with inode numbers.
rmdir /tmp/strange_dir
pwd                     ← Still reports /tmp/strange_dir
ls -lai                 ← Shows empty directory: Total 0
ls -ldi                 ← Shows . with the same inode number it had before,
                          but with a size of 0 and a link count of 0.
cd ..                   ← Puts you back into /tmp

This situation is not perfectly analogous to the one in this question, because, in this other case, strange_dir is removed from /tmp.  But it suggests that cd .. is special, and sometimes works when there's no obvious mechanism by which it could.

Strange difference between pwd and /bin/pwd suggests a possibility as to how this might work.  The shell keeps track of your current directory.  That is, it keeps track of a best guess as to what your current directory is.  It con be fooled by symbolic links and tricks like

mkdir /tmp/foo
cd /tmp/foo
mv /tmp/foo /tmp/foobar

i.e., it will still think that the current directory is /tmp/foo, and so that's what pwd will report, but pwd -P and /bin/pwd will report /tmp/foobar.  So, it may be that, if chdir("..") fails, the shell computes what it thinks your next-level-up directory should be, and goes there absolutely.  (But I suspect that there's more to it than that.)

Answer 3

Thanks for the discussions so far. Following is an explanation from a colleague of mine who is not a member of the Super User community:

/tmp/strange_dir in my case is an NBD/VFS (Network Block Device/Virtual File System) directory. This type of virtual file system differs from more traditional file systems and has its own implementation of the shell commands. So it is not surprising that, when the directory is empty, ls -a shows nothing but cd .. allows going up to its parent directory.