emel fails on relative links

[Liviu Andronic]

Hello
It seems to me that latest SVN fails to correctly parse relative
links. Take this example:
Item: /usr/bin/pwmje
Type: Symbolic Link to /share/passwordmaker-je/pwmje.jar
(which is missing)
Size: 35 bytes

However,
***@liv-laptop:/usr/bin# ls -l pwmje
lrwxrwxrwx 1 root root 35 Dec 4 22:02 pwmje ->
../share/passwordmaker-je/pwmje.jar

I can run the symlink from the command line, but double-clicking in
emel results in a 'What do you want to do with pwmje' dialogue.

Regards
Liviu

[t***@onepost.net]

On Wed, 5 Dec 2012 22:20:52 +0100

Post by Liviu Andronic
It seems to me that latest SVN fails to correctly parse relative

It fails because (presumably) you don't have a directory /share, much less descendants of that.

Post by Liviu Andronic
Item: /usr/bin/pwmje
Type: Symbolic Link to /share/passwordmaker-je/pwmje.jar

Normally, the above should be relative, i.e.
Type: Symbolic Link to ../share/passwordmaker-je/pwmje.jar

When I create a corresponding link here, using emelfm2, the ".." prefix is present.

Post by Liviu Andronic
(which is missing)
Size: 35 bytes

So, question: how did your link get set up badly?

Regards
Tom

[Liviu Andronic]

Post by t***@onepost.net
On Wed, 5 Dec 2012 22:20:52 +0100

Post by Liviu Andronic
It seems to me that latest SVN fails to correctly parse relative

It fails because (presumably) you don't have a directory /share, much less descendants of that.

Post by Liviu Andronic
Item: /usr/bin/pwmje
Type: Symbolic Link to /share/passwordmaker-je/pwmje.jar

Normally, the above should be relative, i.e.
Type: Symbolic Link to ../share/passwordmaker-je/pwmje.jar
When I create a corresponding link here, using emelfm2, the ".." prefix is present.

Post by Liviu Andronic
(which is missing)
Size: 35 bytes

So, question: how did your link get set up badly?

As far as I can see the link is fine. Executing the link works OK from
the console, ls -l shows all in green meaning that the target is
present:
***@liv-laptop:/usr/bin# ls -l pwmje
lrwxrwxrwx 1 root root 35 Dec 4 22:02 pwmje ->
../share/passwordmaker-je/pwmje.jar

and:
***@liv-laptop:/usr/bin# file pwmje
pwmje: symbolic link to `../share/passwordmaker-je/pwmje.jar'

Both commands above indicate a relative link, not an absolute one. It
seems to me that something fails on emel's side, as it considers it an
absolute link.

Liviu

[t***@onepost.net]

On Thu, 6 Dec 2012 07:55:40 +0100

Post by Liviu Andronic

Post by t***@onepost.net
On Wed, 5 Dec 2012 22:20:52 +0100

Post by Liviu Andronic
It seems to me that latest SVN fails to correctly parse relative

It fails because (presumably) you don't have a directory /share, much less descendants of that.

Post by Liviu Andronic
Item: /usr/bin/pwmje
Type: Symbolic Link to /share/passwordmaker-je/pwmje.jar

Normally, the above should be relative, i.e.
Type: Symbolic Link to ../share/passwordmaker-je/pwmje.jar
When I create a corresponding link here, using emelfm2, the ".." prefix is present.

Post by Liviu Andronic
(which is missing)
Size: 35 bytes

So, question: how did your link get set up badly?

As far as I can see the link is fine. Executing the link works OK from
the console, ls -l shows all in green meaning that the target is
lrwxrwxrwx 1 root root 35 Dec 4 22:02 pwmje ->
../share/passwordmaker-je/pwmje.jar
pwmje: symbolic link to `../share/passwordmaker-je/pwmje.jar'
Both commands above indicate a relative link, not an absolute one. It
seems to me that something fails on emel's side, as it considers it an
absolute link.

I don't think so. Your report merely showed that the leading ".." was missing from the displayed information.

What happens if you enable absolute links in emelfm2 configuration ?

Regards
Tom

[Liviu Andronic]

Post by t***@onepost.net
I don't think so. Your report merely showed that the leading ".." was missing from the displayed information.

Well, also that double-clicking the link in emel results in a 'What do
you want to do with pwmje?' dialogue. It doesn't automatically execute
the target.

Post by t***@onepost.net
What happens if you enable absolute links in emelfm2 configuration ?

I see the exact same behaviour when running 'emelfm2 -o'. By 'enable
absolute links ' do you mean that I should uncheck 'interpret relative
paths'? If so, then nothing changes: The link is still not interpreted
correctly.

Liviu

[t***@onepost.net]

On Thu, 6 Dec 2012 11:01:47 +0100

Post by Liviu Andronic

Post by t***@onepost.net
I don't think so. Your report merely showed that the leading ".." was missing from the displayed information.

Well, also that double-clicking the link in emel results in a 'What do
you want to do with pwmje?' dialogue. It doesn't automatically execute
the target.

Post by t***@onepost.net
What happens if you enable absolute links in emelfm2 configuration ?

I see the exact same behaviour when running 'emelfm2 -o'. By 'enable
absolute links ' do you mean that I should uncheck 'interpret relative
paths'? If so, then nothing changes: The link is still not interpreted
correctly.

This problem appears to be a 'feature' of glibc (I've checked 2.12.1, 2.15). Specifically, in some cases, the symlink() function strips leading instance(s) of "../" from the specified relative path of the link-target. This occurs when the first directory in the target path after any "../" is an existing top-level dir, e.g. "../../usr/somepath".

Svn now has code to force emelfm2 to create an absolute link in such cases. Of course, that doesn't help with processing links created by other means.

You might get better results by creating needed links during package installation, instead of during package build/construction. Even better, create absolute links when in doubt.

Regards
Tom

[Liviu Andronic]

Post by t***@onepost.net
This problem appears to be a 'feature' of glibc (I've checked 2.12.1, 2.15). Specifically, in some cases, the symlink() function strips leading instance(s) of "../" from the specified relative path of the link-target. This occurs when the first directory in the target path after any "../" is an existing top-level dir, e.g. "../../usr/somepath".

That's an obscure looking bug, indeed.

Post by t***@onepost.net
Svn now has code to force emelfm2 to create an absolute link in such cases. Of course, that doesn't help with processing links created by other means.

Yes, this helps deal with link creation. But not with link
interpretation. I was wondering whether emel could somehow work around
this bug (as other tools do: bash, Thunar, ls, and even emel's
interpreter when running %p on the .jar). For example Thunar correctly
detects (and prepends '..') the relative link, but instead of
executing it, opens the file using the choices for an (ZIP) archive,
presumably as libmagic indicates.

Perhaps before blindly trusting the results of libmagic, in the
specific cases touched by this bug emel could run a 2nd test using,
say, file:
***@liv-laptop:~$ file /usr/bin/pwmje
/usr/bin/pwmje: symbolic link to `../share/passwordmaker-je/pwmje.jar'

and in case an existing, relative link is detected emel could
internally work around this (by prepending '..').

Is this possible?

Liviu

Post by t***@onepost.net
You might get better results by creating needed links during package installation, instead of during package build/construction. Even better, create absolute links when in doubt.

[t***@onepost.net]

On Sun, 16 Dec 2012 11:30:07 +0100

Post by Liviu Andronic

Post by t***@onepost.net
This problem appears to be a 'feature' of glibc (I've checked 2.12.1, 2.15). Specifically, in some cases, the symlink() function strips leading instance(s) of "../" from the specified relative path of the link-target. This occurs when the first directory in the target path after any "../" is an existing top-level dir, e.g. "../../usr/somepath".

That's an obscure looking bug, indeed.

Post by t***@onepost.net
Svn now has code to force emelfm2 to create an absolute link in such cases. Of course, that doesn't help with processing links created by other means.

Yes, this helps deal with link creation. But not with link
interpretation. I was wondering whether emel could somehow work around
this bug (as other tools do: bash, Thunar, ls, and even emel's
interpreter when running %p on the .jar). For example Thunar correctly
detects (and prepends '..') the relative link, but instead of
executing it, opens the file using the choices for an (ZIP) archive,
presumably as libmagic indicates.
Perhaps before blindly trusting the results of libmagic, in the
specific cases touched by this bug emel could run a 2nd test using,
/usr/bin/pwmje: symbolic link to `../share/passwordmaker-je/pwmje.jar'
and in case an existing, relative link is detected emel could
internally work around this (by prepending '..').
Is this possible?

Needs some thinking.

How to be sure the the general case that a link-target named like '/share/passwordmaker-je/pwmje.jar' is not valid, even though '/share' and any descendant(s) happen not to exist at the time ?

Then, how to know whether to prepend '../' or '../../' or whatever ?

Regards
Tom

[t***@onepost.net]

On Mon, 17 Dec 2012 07:50:57 +1100

Post by t***@onepost.net
On Sun, 16 Dec 2012 11:30:07 +0100

Post by Liviu Andronic

Post by t***@onepost.net
This problem appears to be a 'feature' of glibc (I've checked 2.12.1, 2.15). Specifically, in some cases, the symlink() function strips leading instance(s) of "../" from the specified relative path of the link-target. This occurs when the first directory in the target path after any "../" is an existing top-level dir, e.g. "../../usr/somepath".

That's an obscure looking bug, indeed.

Post by t***@onepost.net
Svn now has code to force emelfm2 to create an absolute link in such cases. Of course, that doesn't help with processing links created by other means.

Yes, this helps deal with link creation. But not with link
interpretation. I was wondering whether emel could somehow work around
this bug (as other tools do: bash, Thunar, ls, and even emel's
interpreter when running %p on the .jar). For example Thunar correctly
detects (and prepends '..') the relative link, but instead of
executing it, opens the file using the choices for an (ZIP) archive,
presumably as libmagic indicates.
Perhaps before blindly trusting the results of libmagic, in the
specific cases touched by this bug emel could run a 2nd test using,
/usr/bin/pwmje: symbolic link to `../share/passwordmaker-je/pwmje.jar'
and in case an existing, relative link is detected emel could
internally work around this (by prepending '..').
Is this possible?

Needs some thinking.
How to be sure the the general case that a link-target named like '/share/passwordmaker-je/pwmje.jar' is not valid, even though '/share' and any descendant(s) happen not to exist at the time ?
Then, how to know whether to prepend '../' or '../../' or whatever ?

Actually, I can't think of a robust way to work around this sort of problem.

As an example, a link whose target is '/lib/somepath' - it's almost certainly a valid target (even if not found). Why bother trying to figure out, or ask the user to decide, whether to treat it specially ?

Regards
Tom