9

In the root directory of my USB flash drive, sometimes when I run ls, the output is normal and it lists the files. At other times, the output is simply one line:

$ ls
.

If I try ls -la at one of those times, I get this:

$ ls -la
ls: .: Invalid argument

If I run ls back to back multiple times, it seems to return either the normal output or the abnormal one basically at random.

ls appears to work normally in other directories. ls $drivename even appears to work fine from the parent directory, and ls .. seems to work fine from a child directory. (Though I can't be 100% sure of the ones that "work normally" since the behavior is indeterminate to begin with.) I tried two other external USB drives and got the same behavior.

What's going on here? I'm on Mac OS X 10.11.3.

Edit: Nice idea, but I don't seem to be using an alias, and /bin/ls gives the same result.

  • 2
    This unusual behavior might be the result of a malfunctioning alias. What happens if you use /bin/ls? – DopeGhoti Mar 3 '16 at 5:54
  • does ls work fine in other directories? – Liam Mar 3 '16 at 6:45
  • /bin/ls gives the same result, sometimes outputting .. ls appears to work normally in other directories. ls NO\ NAME even appears to work fine from the parent directory, and ls .. seems to work fine from a child directory. (Though I can't be 100% sure of the ones that "work normally" since the behavior is indeterminate to begin with.) – leekaiinthesky Mar 3 '16 at 7:37
  • Which file system are you using in those flash drives? Perhaps is some anomaly derived from a windows-based filesystem – RSFalcon7 Mar 11 '16 at 16:33
  • What version of ls are you using? /bin/ls --version should work – RSFalcon7 Mar 11 '16 at 16:34
6

It may be a bug in the filesystem driver for FAT32 on recent versions of OSX. This also only appears to occur when the working directory is at the root of the mounted drive. If it's in a subdirectory or anywhere else on the system things seem to work.

There's some interesting discussion in this thread including system traces. https://github.com/robbyrussell/oh-my-zsh/issues/4161

2

WORKAROUND: (probably part of what the asker would appreciate even if they didn't specifically ask for it)

Refer to the current directory in almost any way other than .. Example:

cd to a subdirectory, and then run ls on the parent directory. That is, enter something like this:

mkdir S; cd S ; /bin/ls -al ..

Or refer to it by it's full pathname. Example:

ls /Volumes/microSD007

For me, either of these workarounds work (that is, they result in the expected output) when ls gives me the same wrong output the OP reported. (And for me, there's no output in dmesg when ls acts oddly.)

I'm seeing the same malfunctions on 10.12.6 in Terminal.app running bash. Same in csh and sh, even after setting TERM to vt100. This workaround works in those shells too.

And I agree there's a bug in stat64, as indicated in the zsh issue thread Neil points us to. (I had thought the issue was caused by flawed and/or fake flash memory, and still wonder if that's a factor sometimes.)

I noticed that this bug also affects:

  • Emacs' dired mode, because it calls ls, and
  • ls when it's used in Emacs' shell mode.
  • 2
    I don't understand why Goro made the edits they did, and no edit summary was provided. I think they made the answer worse, and now I see it's received a -1. I provided a workaround, removing my 'workaround' indicator makes it seem like I'm claiming/trying to provide a direct answer. I think I'm offering more than a comment, but less than an answer. Isn't that to be encouraged? I'm identified a new; wouldn't an edit summary and a reason for the -1 be appropriate? Goro also removed a shorter, better answer that I'd added. I don't get it. – Matthew Elvey Sep 25 '18 at 0:37
  • 1
    I'm on the fence; generally answers need to answer the question, not just provide more information, but working around the problem is probably part of what the asker was looking for even if they didn't specifically mention it. Most of the edits seem kind of unnecessary, and at least one definitely messes up the formatting, so I rolled them back. I'm not sure if the post ever had a downvote, but it's currently at 2 upvotes and 0 downvotes – Michael Mrozek Sep 28 '18 at 20:54
0

If you sometimes remove the drive, then the answer is that each time you reinsert the drive, you must return to the directory using cd. This is because the file descriptor opened by your shell to read the directory is invalidated when the drive is removed, and is not reinitialized automatically when the drive is reinserted (even though you may have used the drive in another terminal or file manager).

If the drive is never removed, then it may be a hardware problem or maybe some software that unmounts the drive for some reason; you should provide the system logs.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.