0

I have been looking for a while, and I cannot fathom why the md5 checksum of a symbolic link equals to the file it points to. In my understanding a symbolic link is still a file. Given that it is empty I would expect a symlink to have an md5 of d41d8cd98f00b204e9800998ecf8427e. (see here)

However testing in practice:

echo Hello World > test
ln -s test test_symlink

Then running:

md5deep test test_symlink

Yields:

e59ff97941044f85df5297e1c302d260  /tmp/test
e59ff97941044f85df5297e1c302d260  /tmp/test_symlink

Does anyone know what I am missing here?

Adonis
  • 4,670
  • 3
  • 37
  • 57
  • The whole *point* of a symbolic link is to be usable as a transparent *pointer* to the destination - i.e. that you can operate on it just the same as if you had operated on the target (opening and reading data, checking metadata, etc). There are calls that can identify symbolic links and tools like `ls` use them. The `md5deep` tool evidently hasn't bothered, probably because nobody is interested in that. – nobody May 24 '17 at 22:31
  • The same reason that `cat test` and `cat test_symlink` print the same output. – Barmar May 24 '17 at 22:51

1 Answers1

3

A symbolic link is transparent to almost all filesystem operations; that's the point of it. When you open a symlink, it actually opens the target file, and it's the contents of the target file that get MD5'd. Only readlink and lstat (and the much more rarely used lchown, lutimes, and open(..., O_PATH|O_NOFOLLOW)) are able to "see" a symlink instead of the file behind it.

hobbs
  • 223,387
  • 19
  • 210
  • 288
  • I saw the md5s being equal indeed. Actually I should have realize the tool does not take into account the nature of a symlink as deleting the target file, and trying to compute the md5 on the broken link yields `md5sum: test_symlink: No such file or directory`. Thanks for the explanation. – Adonis May 24 '17 at 22:51