Re: emel fails on relative links
- From: Liviu Andronic <landronimirc@xxxxxxxxx>
- To: emelfm2@xxxxxxxxxxxxx
- Date: Sun, 16 Dec 2012 11:30:07 +0100
On Fri, Dec 14, 2012 at 11:08 PM, <tpgww@xxxxxxxxxxx> wrote:
> 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.
> 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@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
> 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.
>
--
Users can unsubscribe from the list by sending email to
emelfm2-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject field or by
logging into the web interface.
Other related posts:
