Skip to content

Report a symlink's own name from ReadDir, not its target's - #74

Open
christhomas wants to merge 1 commit into
secsy:masterfrom
antimatter-studios:cth/symlink-name-upstream
Open

Report a symlink's own name from ReadDir, not its target's#74
christhomas wants to merge 1 commit into
secsy:masterfrom
antimatter-studios:cth/symlink-name-upstream

Conversation

@christhomas

Copy link
Copy Markdown

Fixes #60.

LIST renders a symlink as name -> target, and lsRegex captures both as one field. parseLIST then takes the name as filepath.Base of the whole thing.

What that produces

LIST entry Name() today should be
config -> etc/real.conf real.conf config
link.txt -> lorem.txt link.txt -> lorem.txt link.txt
shortcut -> /var/log/messages messages shortcut

The second row is merely malformed. The first and third are the damaging ones: they are plausible filenames, and they are the target's — so a caller listing a directory is handed the name of something that is not in that directory, with nothing to indicate it.

The fix

The name is the left side of the first ->, and only for entries whose mode already says symlink — so a regular file with an arrow in its name is untouched. That case is in the test.

A filename may legitimately contain ->, which makes the split ambiguous. That ambiguity is in LIST's own output rather than in this code: ls renders both cases identically, so no reader can distinguish them.

Tests

symlink_name_test.go — four entries plus a mode check, no server needed. Written first and confirmed failing on the three rows above before the fix was applied.

One note on running them: this branch is off master, so TestMain still requires ./build_test_server.sh. I verified them via the container harness in #73; with that merged these run anywhere, but the fix itself is independent of it and applies cleanly on its own.

Fixes secsy#60.

LIST renders a symlink as "name -> target", and the regex captures both
as one field. The name was then taken as filepath.Base of the whole
thing, which is wrong in two different ways:

    config -> etc/real.conf      reported as  "real.conf"
    link.txt -> lorem.txt        reported as  "link.txt -> lorem.txt"
    shortcut -> /var/log/messages reported as "messages"

The second is merely malformed. The first and third are the damaging
ones: they are plausible filenames, and they are the *target's*, so a
caller listing a directory is handed the name of something that is not
in it and has no way to tell.

The name is now the left side of the first separator. A filename may
legitimately contain " -> ", which makes the split ambiguous, but the
ambiguity is in LIST's own output — it renders both cases identically,
so no reader can do better. Only entries whose mode says symlink are
split at all, so a regular file with an arrow in its name is untouched;
that case is tested.

Verified red before green: the three rows above are what the test
printed against the unfixed parser.
@christhomas christhomas mentioned this pull request Aug 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

ReadDir report linked file name instead of link name

1 participant