Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The trouble with symbolic links

lwn.net

Post reply on HN
Print view View original

111–120 of 126 posts

Re: The trouble with symbolic links

#111

Post by kasabali »

ziml77 wrote: post #5

Interestingly, Windows actually did exactly what's proposed at the end when MS added them in Vista. To minimize the security issues with symlinks, you had to elevate to admin to create them. It was only during the life of Windows 10 that they even added the option to not have to elevate to create them. It was done specifically because symlinks are often shared across systems since they end up in places like git repos…

> It was only during the life of Windows 10 that they even added the option to not have to elevate to create them

Nah it was available from the start in local security policy settings.

https://docs.microsoft.com/en-us/previous-versions/windows/i...

Re: The trouble with symbolic links

#112

Post by kasabali »

samatman wrote: post #75
jhallenworld wrote: post #21

Another problem with hard links: you can not hard link a directory. It would make ".." ambiguous. Also with hard link directories, you would want to be able "rmdir" non-empty directories, just to delete the link. But then you have the problem of reference loops, so how do you reclaim space reliably? You would need a garbage collection algorithm to find data not reachable by root.

A filesystem can afford a very, very slow, mark and sweep.

Tell that to btrfs :)

Re: The trouble with symbolic links

#113

Post by kazinator »

IshKebab wrote: post #109
kazinator wrote: post #106

Earlier quoted context omitted.

You can resolve some .. components without reading the filesystem and there are situations where it is useful to do that, while refusing to treat .. that cannot be resolved without accessing the filesystem. One example is inside the implementation of a function that calculates relative paths: 1> (rel-path "a/b" "../c") "../../../c" 2> (rel-path "../c" "a/b") ** rel-path: from path uses .. to escape common prefix: "..…

That's not really resolving .. though is it? You need both the original path and the output of this function, and one of them always still has .. in it. Interesting nonetheless; thanks.

It does; for instance:

  2> (rel-path "a/../b/../c/.." "f/../g")
  "g"

Re: The trouble with symbolic links

#114

Post by js2 »

inkyoto wrote: post #101
lxgr wrote: post #43

Earlier quoted context omitted.

> You can't normally hard link directories. That's only to avoid loops, as far as I understand. Symlinks do allow loops, but require application programmers to handle them. So maybe we just need better APIs/API contracts around loops, rather than two types of links? > If a file has multiple links, finding them all normally requires scanning the entire file system Couldn't this pretty easily be solved at the file syst…

> Couldn't this pretty easily be solved at the file system level? It will not solve a problem that does not even exist in the first place, but will rather badly break the semantics of the UNIX file system precisely at the file system level. > Just store a back pointer from a file to each of its names. UNIX file systems do not have files in the conventional sense. They have disk block allocations referenced to by an i…

> It is even possible to zero directory entries pointing to an inode.

Historically, fsck would link such anonymous inodes into lost+found using their inode number as their name in the lost+found directory, but I admit having no idea whether this still applies to modern journaled file systems.

Re: The trouble with symbolic links

#115

Post by dredmorbius »

School-Cotton wrote: post #103
littlestymaar wrote: post #9

Earlier quoted context omitted.

That “X − designed in the 70s when we had no idea of anything regarding computers − is fundamentally broken” isn't so surprising after all. In fact, computers are probably the only place in the entire technology landscape where we keep using almost unmodified stuff from the 70s and decided we cannot change it because there's too much things relying on it. I don't like breaking everything all the time more than anyone…

Does writing count as technology? The Chinese characters are thousands of years old.

Writing is a craft or art learned and refined through skill.

I'd argue that it is.

I would probably draw a line between writing and vernacular speech, in the sense of language acquired simply through assimilation and not specifically trained or drilled.

There might be writing which fails that test (e.g., very basic literacy), and of speech which passes (advanced rhetoric, debate, accents and impressions, singing, etc.).

But as a socially-acquired means-to-an-end refined by practice and study, yes, technology.

Re: The trouble with symbolic links

#116

Post by cptparticles »

jandrese wrote: post #70
lxgr wrote: post #43

Earlier quoted context omitted.

> You can't normally hard link directories. That's only to avoid loops, as far as I understand. Symlinks do allow loops, but require application programmers to handle them. So maybe we just need better APIs/API contracts around loops, rather than two types of links? > If a file has multiple links, finding them all normally requires scanning the entire file system Couldn't this pretty easily be solved at the file syst…

> Couldn't this pretty easily be solved at the file system level? Just store a back pointer from a file to each of its names. In theory yes, but no filesystem does this as far as I know.

In Windows both NTFS and ReFS keep backpointers to all their names. They store the file ID of the directory, and the name of the file in the directory. In NTFS these are stored as a special attribute, and in ReFS they reside as rows in the file table.

It's required for a few reasons. Historically NTFS has had an API to query all of a files names and this needs to be done efficiently. And when a file is opened by ID, the file system needs to construct a canonical path for it in the name space.

Source: I am the Microsoft developer that added hardlink support to ReFS. All opinions are my own.

Re: The trouble with symbolic links

#117

Post by joshspankit »

DiggyJohnson wrote: post #67
js2 wrote: post #55

Earlier quoted context omitted.

I tried to construct my argument to make it clear that I'm aware there are ways to solve the issues with hard links, but they have their own sets of trade-offs. For hard links, it's not only that they can cause loops. There are the other issues I outlined (linking across file systems, no single canonical representation of the file in the file system, finding all the links to the file, etc). There's no "just store a b…

Re: Symlink analysis: Well said. > (As an aside, I've been really trying to stop using the word "just" lately as I've learned that things are rarely so simple to justify the word.) Me too! I realized how it immediately frustrated me to hear it used about my domains. I’m constantly having to work to not seem as short/blunt/know-it-all as I feel . I think this word is a connotation trap, because when I use it feels ino…

Totally agree with “just”.

I’ve also tried to eliminate “but” since it usually comes across as “throw out whatever I just said and focus on this instead”.

The language we use is important and worth optimizing.

Re: The trouble with symbolic links

#118

Post by [deleted] »

js2 wrote: post #55
lxgr wrote: post #43

Earlier quoted context omitted.

> You can't normally hard link directories. That's only to avoid loops, as far as I understand. Symlinks do allow loops, but require application programmers to handle them. So maybe we just need better APIs/API contracts around loops, rather than two types of links? > If a file has multiple links, finding them all normally requires scanning the entire file system Couldn't this pretty easily be solved at the file syst…

I tried to construct my argument to make it clear that I'm aware there are ways to solve the issues with hard links, but they have their own sets of trade-offs. For hard links, it's not only that they can cause loops. There are the other issues I outlined (linking across file systems, no single canonical representation of the file in the file system, finding all the links to the file, etc). There's no "just store a b…

[deleted]

Re: The trouble with symbolic links

#119

Post by jimmygrapes »

joshspankit wrote: post #117
DiggyJohnson wrote: post #67

Earlier quoted context omitted.

Re: Symlink analysis: Well said. > (As an aside, I've been really trying to stop using the word "just" lately as I've learned that things are rarely so simple to justify the word.) Me too! I realized how it immediately frustrated me to hear it used about my domains. I’m constantly having to work to not seem as short/blunt/know-it-all as I feel . I think this word is a connotation trap, because when I use it feels ino…

Totally agree with “just”. I’ve also tried to eliminate “but” since it usually comes across as “throw out whatever I just said and focus on this instead”. The language we use is important and worth optimizing.

I noticed recently that I often preface statements with "just wanted to say" or "just chiming in here" and similar. I cringed hard when I realized and am working on eliminating that use of "just". Seems like the same general thing: it's never "just" X.

Re: The trouble with symbolic links

#120

Post by joshspankit »

jimmygrapes wrote: post #119
joshspankit wrote: post #117

Earlier quoted context omitted.

Totally agree with “just”. I’ve also tried to eliminate “but” since it usually comes across as “throw out whatever I just said and focus on this instead”. The language we use is important and worth optimizing.

I noticed recently that I often preface statements with "just wanted to say" or "just chiming in here" and similar. I cringed hard when I realized and am working on eliminating that use of "just". Seems like the same general thing: it's never "just" X.

Right? And that’s a double whammy. You’re minimizing the statement you want to make, and you’re minimizing your place in that conversation.
Post reply on HN