Symlinks in a path pointing to another drive block `ls`

Question

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

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.