Why symlinks do not contain the paths?
 

Why symlinks do not contain the paths? Everywhrre you read about symlinks you are told the symlink file data contains the target file path+name but when you check the file it contains only the name. Where is the path stored? I am not interested in the actual command to find the path. Iam interested to know where the path is actially stored and maybe an explanation why is not together with the name?

What did you do to “check the file”?
On my systemShows the path to the target file.

As I mentioned I am interested to know where the path is actually stored, because it is common belief that the path+name is stored as a text in the file's data/content. If you read the file as a text you do see the name of the target file which corresponds with the file size in bytes of the symlink file and indicate that the path is not stored togetber with the name. The line commands (including the one you used) process the symlink file then show the target path. This doesn't answer my question of where the path is stored?

There is no 'path' in a symlink...it's a pointer to the inode of the resource you linked to. You can DISPLAY it with "ls -l" easily. And I've never heard of the 'common belief' that it's a text file. A bit of basic research will tell you how symlinks are created and what they are.

No offense but I think you should go back to basics before giving advice on forums. I will give you just one good link where you could start:

https://manpages.debian.org/buster/m...link.7.en.html

"A symbolic link is a special type of file whose contents are a string that is the pathname of another file, the file to which the link refers"

How are you reading the contents of the symlink?

From man symlink:

Use readlink to read the contents of a symlink and you will see it does indeed contain the path. But note also that there is no requirement that the object referenced by a symlink actually exists.

There are fast and slow symbolic links. With modern linux filesystems inodes have the capability of directly storing data of small files so with small path names it would be stored within.

https://unix.stackexchange.com/quest...-slow-symlinks

You claim to be interested in knowing things, yet when you're told you respond like this?? I think you should actually read and understand what you post before making snotty comments. Very first line of that page:
...so a pointer...which is exactly what you were told. Further down that same page:
Did you look at readlink??? See how it uses openat, and what that looks at??? The mere fact that you opened a symbolic link file and did *NOT* find the path would indicate that it doesn't store it, wouldn't it???

The path is still a pointer to the inode of the original file; if you move/delete that file, that invalidates the link, and causes a dangling link. A hardlink is different, allowing you to move the file on the same filesystem without breakage.

Good reference, michaelk.

Are you sure that you're not checking a symlink that actually does contain only the name? They exist.

The b.txt symlink contains only "a.txt", while the c.txt symlink contains "/home/dugan/Documents/symlinktest/a.txt".

And anyway, you need to answer this question that was asked of you repeatedly:

How are you "checking" this? Are you mounting the filesystem in Windows and opening the symlinks with Notepad or something?

Post screenshots.

Rox file manager tells me

https://pixhost.to/show/433/464991948_screenshot.jpg

That's wrong. A pointer to an inode is literally a hard link.

@Stefan69

The answer to your question is going to be filesystem-specific, but I found you information on how symbolic links are implemented in ext4.

https://ext4.wiki.kernel.org/index.p...Symbolic_Links

You learn something every day! I had no idea that some symbolic links store the link in the inode. Just out of curiosity, do such links use a data block at all?

I just took a look at the links in my /boot directory. They are of different sizes running from 24 to 38 bytes and the size correlates exactly with the length of the link string.

The first column tells they don't use data blocks:
But: