2

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

Improve this question
4
  • ls -f probably wouldn't. Commented Jul 4, 2021 at 10:04
  • Is your ls an alias (or function)? If yes, to what? Commented 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. Commented Jul 4, 2021 at 10:37
  • @A.B Yes, ls -f does not block... So it can be the sorting or the colorization... Commented Jul 4, 2021 at 11:09

1 Answer 1

Reset to default
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.

Improve this answer
2
  • 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) Commented Jul 4, 2021 at 13:13
  • 1
    @Kusalananda nope, doesn't, see my edit :) Commented Jul 4, 2021 at 13:30

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.