I recently took out some specific directories from my /home directory and put them on an external hard drive that is mounted on another path (/mnt).

Inside my home directory I have created symlinks to some of the old directories in order to access them seamlessly (for instance, I moved my ~/media/music to /mnt/media/music).

Now, if I cd into a directory that contains one of these symlinks (for instance, I created a symlink for /mnt/media/music into ~/media/) and then I issue an ls command, the external hard drive starts spinning and the output of ls is blocked until some data (don't know what) is read from the disk (I suppose, since the spinning).

I was wondering the reason for which it happens. It doesn't seem to be necessary to load anything from the external hard drive just to show the symlink (cding into the symlink and then ls is another thing, though it's not what I'm referring to here). So why does this happen?

Thanks in advance

  • ls -f probably wouldn't.
    – A.B
    Jul 4, 2021 at 10:04
  • Is your ls an alias (or function)? If yes, to what?
    – fra-san
    Jul 4, 2021 at 10:04
  • @fra-san my ls, in fact, an alias to ls -vC --color=auto --group-directories-first. Is the sorting the problem? Anyway, I'll try ls -f as soon as my drive stops spinning.
    – LuxGiammi
    Jul 4, 2021 at 10:37
  • @A.B Yes, ls -f does not block... So it can be the sorting or the colorization...
    – LuxGiammi
    Jul 4, 2021 at 11:09

1 Answer 1


--group-directories-first asks ls to resolve whether a symlink points to a directory or file.

For that, it needs to access the target file system, i.e. your external hard drive.

So, that's why ls takes a long time when you use it.

@Kusalananda raised the very valid question whether coloring wouldn't require the same access: it doesn't; coloring (as far as my ls 8.32 is concerned, with my current very default dircolors) doesn't check the type of target. Way I checked this was by running

cd /tmp
mkdir dir
cd dir
touch testthing
ln -s /doesnotexist deadlink
strace -o /tmp/withlink ls --color
rm deadlink
strace -o /tmp/withoutlink ls --color

and then diff /tmp/withlink /tmp/withoutlink. Things are, aside from randomized memory addresses, identical up to getdents64, which returns a list of dirent'ries which already contain the "is this a symlink?" information. The existence of the target (or its type) is never checked.

  • Doesn't also the coloring require that the target of the symbolic link is accessed? (to see whether it exists and what type it is)
    – Kusalananda
    Jul 4, 2021 at 13:13
  • 1
    @Kusalananda nope, doesn't, see my edit :) Jul 4, 2021 at 13:30
  • I understand now... Thank you very much.
    – LuxGiammi
    Jul 4, 2021 at 15:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .