can't remove directory

[davidmaxwaterman]

• Your Windows build number: (Type ver at a Windows Command Prompt)
  Microsoft Windows [Version 10.0.15063]

• What you're doing and what's happening:
  Trying to remove a directory:

maxw@Downloads$ ls -l | grep '^d' | grep Annex
ls: cannot access 'Annex': No such file or directory
d????????? ? ?    ?             ?            ? Annex
maxw@Downloads$ rmdir Annex
rmdir: failed to remove 'Annex': No such file or directory
maxw@Downloads$

It seems to have gotten into this state as a result of an rm -rf Annex command. Note that cwd is /mnt/c/Users/David/Downloads

• What's wrong / what should be happening instead:
  It should have removed the directory when I did the rm -rf, and I should be able to remove the directory with rmdir and/or list it/etc.

• Strace of the failing command, if applicable: (If <cmd> is failing, then run strace -o strace.txt -ff <cmd>, and post the strace.txt output here)

     1  execve("/bin/rmdir", ["rmdir", "Annex"], [/* 26 vars */]) = 0
     2  brk(NULL)                               = 0x19eb000
     3  access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
     4  mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7ae9820000
     5  access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
     6  open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
     7  fstat(3, {st_mode=S_IFREG|0644, st_size=32178, ...}) = 0
     8  mmap(NULL, 32178, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f7ae9818000
     9  close(3)                                = 0
    10  access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
    11  open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
    12  read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\t\2\0\0\0\0\0"..., 832) = 832
    13  fstat(3, {st_mode=S_IFREG|0755, st_size=1864888, ...}) = 0
    14  mmap(NULL, 3967392, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f7ae9030000
    15  mprotect(0x7f7ae91ef000, 2097152, PROT_NONE) = 0
    16  mmap(0x7f7ae93ef000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1bf000) = 0x7f7ae93ef000
    17  mmap(0x7f7ae93f5000, 14752, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f7ae93f5000
    18  close(3)                                = 0
    19  mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7ae9810000
    20  mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7ae9800000
    21  mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7ae97f0000
    22  arch_prctl(ARCH_SET_FS, 0x7f7ae9800700) = 0
    23  mprotect(0x7f7ae93ef000, 16384, PROT_READ) = 0
    24  mprotect(0x608000, 4096, PROT_READ)     = 0
    25  mprotect(0x7f7ae9625000, 4096, PROT_READ) = 0
    26  munmap(0x7f7ae9818000, 32178)           = 0
    27  brk(NULL)                               = 0x19eb000
    28  brk(0x1a0c000)                          = 0x1a0c000
    29  open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
    30  fstat(3, {st_mode=S_IFREG|0644, st_size=2981280, ...}) = 0
    31  mmap(NULL, 2981280, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f7ae8d58000
    32  close(3)                                = 0
    33  rmdir("Annex")                          = -1 ENOENT (No such file or directory)
    34  open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
    35  fstat(3, {st_mode=S_IFREG|0644, st_size=2995, ...}) = 0
    36  read(3, "# Locale name alias data base.\n#"..., 512) = 512
    37  read(3, "See the\n# GNU General Public Lic"..., 512) = 512
    38  read(3, "nd for the time being for\n# back"..., 512) = 512
    39  read(3, "hese lines were removed\n# becaus"..., 512) = 512
    40  read(3, "8859-1\ngalego\t\tgl_ES.ISO-8859-1\n"..., 512) = 512
    41  read(3, "O.ISO-8859-1 nb_NO.ISO-8859-1\nno"..., 512) = 435
    42  read(3, "", 512)                        = 0
    43  close(3)                                = 0
    44  open("/usr/share/locale/en_GB.UTF-8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
    45  open("/usr/share/locale/en_GB.utf8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
    46  open("/usr/share/locale/en_GB/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
    47  open("/usr/share/locale/en.UTF-8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
    48  open("/usr/share/locale/en.utf8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
    49  open("/usr/share/locale/en/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
    50  open("/usr/share/locale-langpack/en_GB.UTF-8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
    51  open("/usr/share/locale-langpack/en_GB.utf8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
    52  open("/usr/share/locale-langpack/en_GB/LC_MESSAGES/coreutils.mo", O_RDONLY) = 3
    53  fstat(3, {st_mode=S_IFREG|0644, st_size=14622, ...}) = 0
    54  mmap(NULL, 14622, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f7ae9823000
    55  close(3)                                = 0
    56  open("/usr/share/locale-langpack/en.UTF-8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
    57  open("/usr/share/locale-langpack/en.utf8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
    58  open("/usr/share/locale-langpack/en/LC_MESSAGES/coreutils.mo", O_RDONLY) = 3
    59  fstat(3, {st_mode=S_IFREG|0644, st_size=619, ...}) = 0
    60  mmap(NULL, 619, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f7ae9822000
    61  close(3)                                = 0
    62  write(2, "rmdir: ", 7)                  = 7
    63  write(2, "failed to remove 'Annex'", 24) = 24
    64  open("/usr/share/locale/en_GB.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
    65  open("/usr/share/locale/en_GB.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
    66  open("/usr/share/locale/en_GB/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
    67  open("/usr/share/locale/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
    68  open("/usr/share/locale/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
    69  open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
    70  open("/usr/share/locale-langpack/en_GB.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
    71  open("/usr/share/locale-langpack/en_GB.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
    72  open("/usr/share/locale-langpack/en_GB/LC_MESSAGES/libc.mo", O_RDONLY) = 3
    73  fstat(3, {st_mode=S_IFREG|0644, st_size=3537, ...}) = 0
    74  mmap(NULL, 3537, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f7ae981f000
    75  close(3)                                = 0
    76  open("/usr/share/locale-langpack/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
    77  open("/usr/share/locale-langpack/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
    78  open("/usr/share/locale-langpack/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
    79  write(2, ": No such file or directory", 27) = 27
    80  write(2, "\n", 1)                       = 1
    81  close(1)                                = 0
    82  close(2)                                = 0
    83  exit_group(1)                           = ?
    84  +++ exited with 1 +++

See our contributing instructions for assistance.

[CherryDT]

Check with a tool like Process Explorer whether something still has a handle to the directory open. I would assume that some other process (probably even outside of WSL) hasn't released all handles to the directory yet, so it is in a "marked for deletion but not actually deleted yet" state.

Maybe it is the current working directory of some process?

This is just how the deletion semantics in the Windows filesystem work (you are in a /mnt path after all).

[davidmaxwaterman]

Yeah, looks like it might have been something like that...it wasn't there after a reboot anyway without any more attempts to delete it anyway.

Is this something that can be fixed? I've used Linux/Unix for decades and never had something like this. Perhaps it's just something peculiar to Microsoft s/w that we have to put up with when we use files in /mnt/c?

[rodrymbo]

Well, the error message is No such file or directory. That would seem to indicate that it is not there to remove, rather than being a problem with rmdir not removing it?

In addition to the possibility that some other program is holding it open (which should give a different error message?) I'd look at the possibility that some view of the filesystem has not yet figured out that the directory has been deleted already, or that Windows (which is doing the deleting) has marked it deleted but hasn't finished its housekeeping for whatever reason, or the actual changes in the filesystem haven't been sync'd to WSL ... something along those lines.

But all's well that ends well, I suppose.

[davidmaxwaterman]

Well, I suppose I kept trying to delete it because ls kept saying it was there...perhaps ls shouldn't include it in its output (or output something more explicit than ?????????. It's quite strange to see from a seasoned *ix user anyway.

[CherryDT]

The root cause of this is #966 (see also #1956, #1535 and friends). You see ???? because the entry is reported in the directory listing, but stat on it fails with ENOENT.

I just had a similar situation again, and my two cents are that even though it can't be simply fixed at the moment, it would maybe be better if a stat on a "zombie" directory would return EACCES instead of ENOENT (similar to how Windows behaves) because ENOENT can confuse libraries even more. For example, some mkdir -p-like algorithms can get into an endless loop or fail with stack overflow (this is what happened with the npm package mkdirp now) because they first try to create the target directory, and if it doesn't work, they try to recursively apply their algorithm on the parent directory and afterwards on the target again. This leads to a loop between x/y/zombie which returns ENOENT on stat and x/y which returns EEXIST on mkdir (as it should). Returning a different error such as EACCES would break this loop.

[davidmaxwaterman]

I wonder what 'ls' does with an EACCES failure?

[CherryDT]

If I'm reading http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/ls.c correctly, I would say it does the same thing it does at #1877 where the error was EIO. It would probably show ls: cannot access '/mnt/c/some/item': Access denied.

Only ENOENT has a special case according to the source code I linked above, because it can be caused by other things like dangling symlinks and ls tries to call lstat then (which also fails), and at the end the normal code for displaying the data is run, but f->stat_ok == false which causes it to use ? everywhere.

That's why I meant that ENOENT is probably a bad choice as error code because it will make tools believe that they can create a file/folder with that name, which they can't, and it can cause weirder failure modes than EACCES or EIO, I believe. In fact it is even weirder that also any attempt to create a file/folder with that name will return ENOENT which makes no real sense and causes the situation I described above because it usually means that a parent of the target file does not yet exist.

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!