But them what if it's a symlink to "music-dir-something-something" and
such (min ...) will cut it to "music-dir", resulting in t for
string-equal check, while symlink does not actually refer to same dir?
So this fix doesn't look right.
And I'm not entirely sure I'm understanding the problem correctly in
the first place, as it looks like there was a bug anyway, given that
any width can be longer than other, yet string was cut using only one
Given that it looks like something simple and maybe typical wrt
symlinks, thought I'd should ask for clarification on what this code
does and maybe what's the right way to fix it?
Also, I've seen this (args-out-of-range ...) error pop-up with
(substring ...) in other unexpected places for me, like completion
system suddenly stops working until emacs restart with no clear
backtrace (assuming it was optimized-out in .elc, same as here) and such.
So I suspect it's actually an upstream change in emacs that caused this
bug to surface - e.g. maybe (substring ...) didn't raise such error before.
But code looks bit strange to me anyway, due that
"music-dir-something-something cut to music-dir" case.
GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.10) ...
I'm also a bit sleep-deprived and distracted atm, so maybe just can't
think right about the issue and it's actually a no-brainer (esp. if
it's indeed some kind of typical symlink check).
Thanks in advance for any info/clarification.
Re: Error from substring-of-symlink in emms-source-file-directory-tree-internal
On Fri, 24 Jan 2020 11:32:01 +0500
Mike Kazantsev <[hidden email]> wrote:
> One way to fix it can be to use:
> (substring symlink 0
> (min (string-width dir) (string-width symlink)))
> But them what if it's a symlink to "music-dir-something-something" and
> such (min ...) will cut it to "music-dir", resulting in t for
> string-equal check, while symlink does not actually refer to same dir?
> So this fix doesn't look right.
> And I'm not entirely sure I'm understanding the problem correctly in
> the first place, as it looks like there was a bug anyway, given that
> any width can be longer than other, yet string was cut using only one
> of them.
At the risk of biasing any potential info/solution some more, feel like
proper (tm) way to check for any kind of loops would be getting
(file-truename ...) for both paths and then checking if one is subdir
But it doesn't look like (file-truename ...) uses realpath(3) under the
hood, so not entirely sure if it works same as libc's realpath() and
can be used here.