[go: up one dir, main page]

|
|
Log in / Subscribe / Register

The trouble with symbolic links

The trouble with symbolic links

Posted Jul 12, 2022 20:50 UTC (Tue) by civodul (guest, #58311)
Parent article: The trouble with symbolic links

I view the *at function family as the right thing; it was wrong for 'open' et al. to take an implicit "root" parameter (the Hurd file system interface is very much like that: every file system operation takes a capability to the root directory on which it operates, starting with 'file_name_lookup', which is like 'openat').

In some cases, such as the Stow/Guix/Nix examples, symlinks could be replaced by a unionfs. Maybe a way forward?


to post comments

The trouble with symbolic links

Posted Sep 8, 2022 12:32 UTC (Thu) by nix (subscriber, #2304) [Link]

A unionfs of thousands of filesystems is going to be hilariously slow. You're replacing an O(smallnum) lookup when a symlink is resolved with an O(n) where n == number of installed packages for *every file lookup*, as it works through all the layers.

Or did you mean to suggest some other, cleverer trick that I hadn't thought of? (Quite likely, because the naive approach is obviously a disaster.)


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds