3

I was monitoring a directory containing downloads from Google Chrome with ls -la and got this in the output:

-?????????  ? ?     ?            ?            ? 'Unconfirmed 784300.crdownload'

I've never seen such question marks in the output.

There were other files in the directory with normal metadata output. When I ran ls -la again the output was all normal; the file still had the same name but the metadata was now visible. Later when the download finished the file was renamed to its final name, as expected.

I checked /var/log/syslog and dmesg output and didn't see any kernel messages.

I wonder if I hit some race condition? I wonder if there is a brief moment after the file is first created where the information is not yet available?

ext4 filesystem with seemingly standard mount options (rw,relatime,errors=remount-ro), 5.4.0-59-generic kernel on Ubuntu 20.04.1 LTS

1 Answers1

4

That's a (temporary?) file which had disappeared in the time between ls reading its directory entry and trying to get the metadata from its inode.

You can reproduce that by stopping ls just before it calls lstat on a file, removing that file, and then letting it continue:

$ mkdir dir; touch dir/file
$ gdb -q ls
Reading symbols from ls...(no debugging symbols found)...done.
(gdb) br __lxstat
Breakpoint 1 at 0x4200
(gdb) r -l dir
...
Breakpoint 1, __GI___lxstat (vers=1, name=0x7fffffffdfca "dir",
    buf=0x55555557c538) at ../sysdeps/unix/sysv/linux/wordsize-64/lxstat.c:34
(gdb) c
...
Breakpoint 1, __GI___lxstat (vers=1, name=0x7fffffffd3f0 "dir/file",
    buf=0x55555557c538) at ../sysdeps/unix/sysv/linux/wordsize-64/lxstat.c:34
...
(gdb) shell rm dir/file
(gdb) c
...
/usr/bin/ls: cannot access 'dir/file': No such file or directory
total 0
-????????? ? ? ? ?            ? file

wonder if I hit some race condition?

Kind of, but not really. It's simply the fact that ls does not hold a lock on the filesystem while it does its stuff ;-)

In any case, this is not a symptom of filesystem corruption or anything like that.