Why C readlink() has ELOOP as a possible error
up vote
1
down vote
favorite
Background
I read about the Open Group Specification about readlink(), and there is an error called ELOOP
, which indicates "A loop exists in symbolic links encountered during resolution of the path argument.", so I assume this function will continue path resolution until encountering a non-link file.
However, I did an experiment and found that readlink()
only resolve the passed in path
argument and just stops there but not keep resolving until reaching a non-link file.
My Problem
- If it's for
realpath()
, that makes all the sense to haveELOOP
as a possible error. But why doesELOOP
even exist forreadlink()
while it only resolves the path once? - I saw this on the spec "The [ELOOP] optional error condition is added to align with the IEEE P1003.1a draft standard", does that mean the behavior of
readlink()
(whether it keeps resolving until reaching a non-link file) depends on implementation?
my gcc version is 8.2.1
c symlink readlink
add a comment |
up vote
1
down vote
favorite
Background
I read about the Open Group Specification about readlink(), and there is an error called ELOOP
, which indicates "A loop exists in symbolic links encountered during resolution of the path argument.", so I assume this function will continue path resolution until encountering a non-link file.
However, I did an experiment and found that readlink()
only resolve the passed in path
argument and just stops there but not keep resolving until reaching a non-link file.
My Problem
- If it's for
realpath()
, that makes all the sense to haveELOOP
as a possible error. But why doesELOOP
even exist forreadlink()
while it only resolves the path once? - I saw this on the spec "The [ELOOP] optional error condition is added to align with the IEEE P1003.1a draft standard", does that mean the behavior of
readlink()
(whether it keeps resolving until reaching a non-link file) depends on implementation?
my gcc version is 8.2.1
c symlink readlink
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
Background
I read about the Open Group Specification about readlink(), and there is an error called ELOOP
, which indicates "A loop exists in symbolic links encountered during resolution of the path argument.", so I assume this function will continue path resolution until encountering a non-link file.
However, I did an experiment and found that readlink()
only resolve the passed in path
argument and just stops there but not keep resolving until reaching a non-link file.
My Problem
- If it's for
realpath()
, that makes all the sense to haveELOOP
as a possible error. But why doesELOOP
even exist forreadlink()
while it only resolves the path once? - I saw this on the spec "The [ELOOP] optional error condition is added to align with the IEEE P1003.1a draft standard", does that mean the behavior of
readlink()
(whether it keeps resolving until reaching a non-link file) depends on implementation?
my gcc version is 8.2.1
c symlink readlink
Background
I read about the Open Group Specification about readlink(), and there is an error called ELOOP
, which indicates "A loop exists in symbolic links encountered during resolution of the path argument.", so I assume this function will continue path resolution until encountering a non-link file.
However, I did an experiment and found that readlink()
only resolve the passed in path
argument and just stops there but not keep resolving until reaching a non-link file.
My Problem
- If it's for
realpath()
, that makes all the sense to haveELOOP
as a possible error. But why doesELOOP
even exist forreadlink()
while it only resolves the path once? - I saw this on the spec "The [ELOOP] optional error condition is added to align with the IEEE P1003.1a draft standard", does that mean the behavior of
readlink()
(whether it keeps resolving until reaching a non-link file) depends on implementation?
my gcc version is 8.2.1
c symlink readlink
c symlink readlink
edited Nov 10 at 14:09
melpomene
55.8k54387
55.8k54387
asked Nov 10 at 13:58
David Chen
4891614
4891614
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
3
down vote
accepted
readlink
gives you the immediate target of a symbolic link. But what if resolving the path to the symbolic link involves another symlink?
Take readlink("/foo/bar")
as an example. It's supposed to return the link target of bar
, but if /foo
is a symlink pointing to itself, you'll get ELOOP
because readlink
has to resolve the directory part before getting to the final entry.
See also man path_resolution
.
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
accepted
readlink
gives you the immediate target of a symbolic link. But what if resolving the path to the symbolic link involves another symlink?
Take readlink("/foo/bar")
as an example. It's supposed to return the link target of bar
, but if /foo
is a symlink pointing to itself, you'll get ELOOP
because readlink
has to resolve the directory part before getting to the final entry.
See also man path_resolution
.
add a comment |
up vote
3
down vote
accepted
readlink
gives you the immediate target of a symbolic link. But what if resolving the path to the symbolic link involves another symlink?
Take readlink("/foo/bar")
as an example. It's supposed to return the link target of bar
, but if /foo
is a symlink pointing to itself, you'll get ELOOP
because readlink
has to resolve the directory part before getting to the final entry.
See also man path_resolution
.
add a comment |
up vote
3
down vote
accepted
up vote
3
down vote
accepted
readlink
gives you the immediate target of a symbolic link. But what if resolving the path to the symbolic link involves another symlink?
Take readlink("/foo/bar")
as an example. It's supposed to return the link target of bar
, but if /foo
is a symlink pointing to itself, you'll get ELOOP
because readlink
has to resolve the directory part before getting to the final entry.
See also man path_resolution
.
readlink
gives you the immediate target of a symbolic link. But what if resolving the path to the symbolic link involves another symlink?
Take readlink("/foo/bar")
as an example. It's supposed to return the link target of bar
, but if /foo
is a symlink pointing to itself, you'll get ELOOP
because readlink
has to resolve the directory part before getting to the final entry.
See also man path_resolution
.
answered Nov 10 at 14:03
melpomene
55.8k54387
55.8k54387
add a comment |
add a comment |
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%2fstackoverflow.com%2fquestions%2f53239691%2fwhy-c-readlink-has-eloop-as-a-possible-error%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