Why does Linux allow a symbolic link to itself?
0
Because of a typo I found out that this is allowed: ln -s useless useless.
Then, as expected ls useless/* triggers this error message:
ls: cannot access 'useless/*': Too many levels of symbolic links
What are the situations which need this so it is allowed and ln therefore does accept it?
I was testing it on SLES 12.4.
filesystems filenames symlink
asked 3 hours ago
Al BundyAl Bundy
4122521
|
show 1 more comment
0
Because of a typo I found out that this is allowed: ln -s useless useless.
Then, as expected ls useless/* triggers this error message:
ls: cannot access 'useless/*': Too many levels of symbolic links
What are the situations which need this so it is allowed and ln therefore does accept it?
I was testing it on SLES 12.4.
filesystems filenames symlink
asked 3 hours ago
Al BundyAl Bundy
4122521
To what lengths do you feel it would be appropriate to go to avoid symbolic link loops? Note that a symbolic link may also point to its grand-parent directory, or to its parent (these are also loops).
– Kusalananda
3 hours ago
@Kusalananda For me I would implementlnthat way that I would check if the new symbolic link triggers the error and print - at least - a warning. My question is why is the obvious useless constellation allowed.
– Al Bundy
3 hours ago
A symlink could start (or stop) pointing to itself if it's moved elsewhere, or if its parent directory is renamed, or an infinite number of other scenarios. Shouldmv,cp, etc. all check and print an error for this condition, which, contrary to what you say, it's not an "erroneous modification of the file system" (symlinks by definition, are not validated and can contain anything).
– mosvy
2 hours ago
@mosvy I am not talking - and I tried to explain it in my comments - about what can happen AFTER the symlink has been created. I am only talking about the inconsistent situation WHEN the symlink is created. @ symlinks by definition, are not validated and can contain anything seems to be the correct answer.
– Al Bundy
2 hours ago
There's no inconsistency -- symlink loops are allowed by the filesystem. And you cannot make sure that you won't create a symlink loop no matter how hard you try (you can inadvertently create a symlink loop even when creating a hard link ;-)), so a special case for simple, trivial cases like that would be pointless.
– mosvy
2 hours ago
|
show 1 more comment
0
0
0
Because of a typo I found out that this is allowed: ln -s useless useless.
Then, as expected ls useless/* triggers this error message:
ls: cannot access 'useless/*': Too many levels of symbolic links
What are the situations which need this so it is allowed and ln therefore does accept it?
I was testing it on SLES 12.4.
filesystems filenames symlink
asked 3 hours ago
Al BundyAl Bundy
4122521
Because of a typo I found out that this is allowed: ln -s useless useless.
Then, as expected ls useless/* triggers this error message:
ls: cannot access 'useless/*': Too many levels of symbolic links
What are the situations which need this so it is allowed and ln therefore does accept it?
I was testing it on SLES 12.4.
filesystems filenames symlink
filesystems filenames symlink
asked 3 hours ago
Al BundyAl Bundy
4122521
asked 3 hours ago
Al BundyAl Bundy
4122521
edited 3 hours ago
Al Bundy
asked 3 hours ago
Al BundyAl Bundy
4122521
asked 3 hours ago
Al BundyAl Bundy
4122521
asked 3 hours ago
Al BundyAl Bundy
4122521
4122521
To what lengths do you feel it would be appropriate to go to avoid symbolic link loops? Note that a symbolic link may also point to its grand-parent directory, or to its parent (these are also loops).
– Kusalananda
3 hours ago
@Kusalananda For me I would implementlnthat way that I would check if the new symbolic link triggers the error and print - at least - a warning. My question is why is the obvious useless constellation allowed.
– Al Bundy
3 hours ago
A symlink could start (or stop) pointing to itself if it's moved elsewhere, or if its parent directory is renamed, or an infinite number of other scenarios. Shouldmv,cp, etc. all check and print an error for this condition, which, contrary to what you say, it's not an "erroneous modification of the file system" (symlinks by definition, are not validated and can contain anything).
– mosvy
2 hours ago
@mosvy I am not talking - and I tried to explain it in my comments - about what can happen AFTER the symlink has been created. I am only talking about the inconsistent situation WHEN the symlink is created. @ symlinks by definition, are not validated and can contain anything seems to be the correct answer.
– Al Bundy
2 hours ago
There's no inconsistency -- symlink loops are allowed by the filesystem. And you cannot make sure that you won't create a symlink loop no matter how hard you try (you can inadvertently create a symlink loop even when creating a hard link ;-)), so a special case for simple, trivial cases like that would be pointless.
– mosvy
2 hours ago
|
show 1 more comment
To what lengths do you feel it would be appropriate to go to avoid symbolic link loops? Note that a symbolic link may also point to its grand-parent directory, or to its parent (these are also loops).
– Kusalananda
3 hours ago
@Kusalananda For me I would implementlnthat way that I would check if the new symbolic link triggers the error and print - at least - a warning. My question is why is the obvious useless constellation allowed.
– Al Bundy
3 hours ago
A symlink could start (or stop) pointing to itself if it's moved elsewhere, or if its parent directory is renamed, or an infinite number of other scenarios. Shouldmv,cp, etc. all check and print an error for this condition, which, contrary to what you say, it's not an "erroneous modification of the file system" (symlinks by definition, are not validated and can contain anything).
– mosvy
2 hours ago
@mosvy I am not talking - and I tried to explain it in my comments - about what can happen AFTER the symlink has been created. I am only talking about the inconsistent situation WHEN the symlink is created. @ symlinks by definition, are not validated and can contain anything seems to be the correct answer.
– Al Bundy
2 hours ago
There's no inconsistency -- symlink loops are allowed by the filesystem. And you cannot make sure that you won't create a symlink loop no matter how hard you try (you can inadvertently create a symlink loop even when creating a hard link ;-)), so a special case for simple, trivial cases like that would be pointless.
– mosvy
2 hours ago
To what lengths do you feel it would be appropriate to go to avoid symbolic link loops? Note that a symbolic link may also point to its grand-parent directory, or to its parent (these are also loops).
– Kusalananda
3 hours ago
To what lengths do you feel it would be appropriate to go to avoid symbolic link loops? Note that a symbolic link may also point to its grand-parent directory, or to its parent (these are also loops).
– Kusalananda
3 hours ago
@Kusalananda For me I would implement
ln that way that I would check if the new symbolic link triggers the error and print - at least - a warning. My question is why is the obvious useless constellation allowed.– Al Bundy
3 hours ago
@Kusalananda For me I would implement
ln that way that I would check if the new symbolic link triggers the error and print - at least - a warning. My question is why is the obvious useless constellation allowed.– Al Bundy
3 hours ago
A symlink could start (or stop) pointing to itself if it's moved elsewhere, or if its parent directory is renamed, or an infinite number of other scenarios. Should
mv, cp, etc. all check and print an error for this condition, which, contrary to what you say, it's not an "erroneous modification of the file system" (symlinks by definition, are not validated and can contain anything).– mosvy
2 hours ago
A symlink could start (or stop) pointing to itself if it's moved elsewhere, or if its parent directory is renamed, or an infinite number of other scenarios. Should
mv, cp, etc. all check and print an error for this condition, which, contrary to what you say, it's not an "erroneous modification of the file system" (symlinks by definition, are not validated and can contain anything).– mosvy
2 hours ago
@mosvy I am not talking - and I tried to explain it in my comments - about what can happen AFTER the symlink has been created. I am only talking about the inconsistent situation WHEN the symlink is created. @ symlinks by definition, are not validated and can contain anything seems to be the correct answer.
– Al Bundy
2 hours ago
@mosvy I am not talking - and I tried to explain it in my comments - about what can happen AFTER the symlink has been created. I am only talking about the inconsistent situation WHEN the symlink is created. @ symlinks by definition, are not validated and can contain anything seems to be the correct answer.
– Al Bundy
2 hours ago
There's no inconsistency -- symlink loops are allowed by the filesystem. And you cannot make sure that you won't create a symlink loop no matter how hard you try (you can inadvertently create a symlink loop even when creating a hard link ;-)), so a special case for simple, trivial cases like that would be pointless.
– mosvy
2 hours ago
There's no inconsistency -- symlink loops are allowed by the filesystem. And you cannot make sure that you won't create a symlink loop no matter how hard you try (you can inadvertently create a symlink loop even when creating a hard link ;-)), so a special case for simple, trivial cases like that would be pointless.
– mosvy
2 hours ago
|
show 1 more comment
1 Answer
1
active
oldest
votes
1
There is no need fr this to be allowed; it just doesn’t care what the symlink points to, even to non-existing path (or the symlink itself).
One could imagine forbidding making a symlink to a non existing path, but there would be several problems:
- There’s no backreference to the symlink, so it would still be possible to build a symlink to a file and then remove the file to make the symlink dangling.
- A symlink may point to a different filesystem which might be unmounted.
- The filesystem that contains the symlink may be mounted on several mount points simultaneously, some where the symlink points to existing path and other where it points to non-existing path.
- Symlinks that point to absolute path may point to an existing path for some processes, and be dangling for others, since different processes may have a different root directory.
Once you have a symlink that points to a non existing path, you may rename the symlink to that it points to itself. So, if you wanted to forbid symlinks that point to themselves, you would need to restrict the renaming.
answered 3 hours ago
user2233709user2233709
1,063312
This is all correct and you describe situations which happens AFTER the symlink has been created. I am just wondering why an obviously erroneous modification in the file system is allowed when the symlink is created
– Al Bundy
3 hours ago
@AlBundy Why would it bother? Is it worse than a dangling symlink?
– user2233709
3 hours ago
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f502985%2fwhy-does-linux-allow-a-symbolic-link-to-itself%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
1
There is no need fr this to be allowed; it just doesn’t care what the symlink points to, even to non-existing path (or the symlink itself).
One could imagine forbidding making a symlink to a non existing path, but there would be several problems:
- There’s no backreference to the symlink, so it would still be possible to build a symlink to a file and then remove the file to make the symlink dangling.
- A symlink may point to a different filesystem which might be unmounted.
- The filesystem that contains the symlink may be mounted on several mount points simultaneously, some where the symlink points to existing path and other where it points to non-existing path.
- Symlinks that point to absolute path may point to an existing path for some processes, and be dangling for others, since different processes may have a different root directory.
Once you have a symlink that points to a non existing path, you may rename the symlink to that it points to itself. So, if you wanted to forbid symlinks that point to themselves, you would need to restrict the renaming.
answered 3 hours ago
user2233709user2233709
1,063312
This is all correct and you describe situations which happens AFTER the symlink has been created. I am just wondering why an obviously erroneous modification in the file system is allowed when the symlink is created
– Al Bundy
3 hours ago
@AlBundy Why would it bother? Is it worse than a dangling symlink?
– user2233709
3 hours ago
add a comment |
1
There is no need fr this to be allowed; it just doesn’t care what the symlink points to, even to non-existing path (or the symlink itself).
One could imagine forbidding making a symlink to a non existing path, but there would be several problems:
- There’s no backreference to the symlink, so it would still be possible to build a symlink to a file and then remove the file to make the symlink dangling.
- A symlink may point to a different filesystem which might be unmounted.
- The filesystem that contains the symlink may be mounted on several mount points simultaneously, some where the symlink points to existing path and other where it points to non-existing path.
- Symlinks that point to absolute path may point to an existing path for some processes, and be dangling for others, since different processes may have a different root directory.
Once you have a symlink that points to a non existing path, you may rename the symlink to that it points to itself. So, if you wanted to forbid symlinks that point to themselves, you would need to restrict the renaming.
answered 3 hours ago
user2233709user2233709
1,063312
This is all correct and you describe situations which happens AFTER the symlink has been created. I am just wondering why an obviously erroneous modification in the file system is allowed when the symlink is created
– Al Bundy
3 hours ago
@AlBundy Why would it bother? Is it worse than a dangling symlink?
– user2233709
3 hours ago
add a comment |
1
1
1
There is no need fr this to be allowed; it just doesn’t care what the symlink points to, even to non-existing path (or the symlink itself).
One could imagine forbidding making a symlink to a non existing path, but there would be several problems:
- There’s no backreference to the symlink, so it would still be possible to build a symlink to a file and then remove the file to make the symlink dangling.
- A symlink may point to a different filesystem which might be unmounted.
- The filesystem that contains the symlink may be mounted on several mount points simultaneously, some where the symlink points to existing path and other where it points to non-existing path.
- Symlinks that point to absolute path may point to an existing path for some processes, and be dangling for others, since different processes may have a different root directory.
Once you have a symlink that points to a non existing path, you may rename the symlink to that it points to itself. So, if you wanted to forbid symlinks that point to themselves, you would need to restrict the renaming.
answered 3 hours ago
user2233709user2233709
1,063312
There is no need fr this to be allowed; it just doesn’t care what the symlink points to, even to non-existing path (or the symlink itself).
One could imagine forbidding making a symlink to a non existing path, but there would be several problems:
- There’s no backreference to the symlink, so it would still be possible to build a symlink to a file and then remove the file to make the symlink dangling.
- A symlink may point to a different filesystem which might be unmounted.
- The filesystem that contains the symlink may be mounted on several mount points simultaneously, some where the symlink points to existing path and other where it points to non-existing path.
- Symlinks that point to absolute path may point to an existing path for some processes, and be dangling for others, since different processes may have a different root directory.
Once you have a symlink that points to a non existing path, you may rename the symlink to that it points to itself. So, if you wanted to forbid symlinks that point to themselves, you would need to restrict the renaming.
answered 3 hours ago
user2233709user2233709
1,063312
answered 3 hours ago
user2233709user2233709
1,063312
answered 3 hours ago
user2233709user2233709
1,063312
answered 3 hours ago
user2233709user2233709
1,063312
1,063312
This is all correct and you describe situations which happens AFTER the symlink has been created. I am just wondering why an obviously erroneous modification in the file system is allowed when the symlink is created
– Al Bundy
3 hours ago
@AlBundy Why would it bother? Is it worse than a dangling symlink?
– user2233709
3 hours ago
add a comment |
This is all correct and you describe situations which happens AFTER the symlink has been created. I am just wondering why an obviously erroneous modification in the file system is allowed when the symlink is created
– Al Bundy
3 hours ago
@AlBundy Why would it bother? Is it worse than a dangling symlink?
– user2233709
3 hours ago
This is all correct and you describe situations which happens AFTER the symlink has been created. I am just wondering why an obviously erroneous modification in the file system is allowed when the symlink is created
– Al Bundy
3 hours ago
This is all correct and you describe situations which happens AFTER the symlink has been created. I am just wondering why an obviously erroneous modification in the file system is allowed when the symlink is created
– Al Bundy
3 hours ago
@AlBundy Why would it bother? Is it worse than a dangling symlink?
– user2233709
3 hours ago
@AlBundy Why would it bother? Is it worse than a dangling symlink?
– user2233709
3 hours ago
add a comment |
draft saved
draft discarded
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f502985%2fwhy-does-linux-allow-a-symbolic-link-to-itself%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
To what lengths do you feel it would be appropriate to go to avoid symbolic link loops? Note that a symbolic link may also point to its grand-parent directory, or to its parent (these are also loops).
– Kusalananda
3 hours ago
@Kusalananda For me I would implement
lnthat way that I would check if the new symbolic link triggers the error and print - at least - a warning. My question is why is the obvious useless constellation allowed.– Al Bundy
3 hours ago
A symlink could start (or stop) pointing to itself if it's moved elsewhere, or if its parent directory is renamed, or an infinite number of other scenarios. Should
mv,cp, etc. all check and print an error for this condition, which, contrary to what you say, it's not an "erroneous modification of the file system" (symlinks by definition, are not validated and can contain anything).– mosvy
2 hours ago
@mosvy I am not talking - and I tried to explain it in my comments - about what can happen AFTER the symlink has been created. I am only talking about the inconsistent situation WHEN the symlink is created. @ symlinks by definition, are not validated and can contain anything seems to be the correct answer.
– Al Bundy
2 hours ago
There's no inconsistency -- symlink loops are allowed by the filesystem. And you cannot make sure that you won't create a symlink loop no matter how hard you try (you can inadvertently create a symlink loop even when creating a hard link ;-)), so a special case for simple, trivial cases like that would be pointless.
– mosvy
2 hours ago