The trouble with symbolic links

by jwilk • 4 years ago

227 122 4 years ago

smelbe• 4 years ago

There doesn't seem to be a way to batch together operations that involve walking through directories and symlinks to do something to a file. This seems to be a major source of complexity.

klodolph2• 4 years ago

Could you elaborate? Seems like there’s a bunch of things that can’t be batched together on an ordinary file, without involving symlinks.

masklinn4• 4 years ago

What they (and TFA) are saying is that there is no transactional view of the FS. If you could work in “repeatable read” (only and always see the state of the FS before you started the transaction) symlink races wouldn’t be possible.

rwmj• 4 years ago

I always thought Unix v7+ should have added some kind way to do atomic groups of syscalls, eg:

  begin_transaction ();
  lstat ("/path", ...);
  lstat ("/path/foo", ...);
  commit ();

In Unix v7 mkdir was not a system call. It was a setuid program implemented using mknod + link. That was racy so the mkdir(2) system call was added. But it could have been solved more generally (and more elegantly) by adding transactions.

It could also solve the whole thing with ending up with zero-length files because you didn't use the right incantation to update a file atomically on ext4 (https://thunk.org/tytso/blog/2009/03/12/delayed-allocation-a...).

bhawks2• 4 years ago

A general purpose transactional interface widene the error space to include cross process deadlocks / denial of service not to mention performance issues.

amaranth• 4 years ago

Wasn't making userspace handle these kinds of things a big part of "worse is better"?

jmillikin2• 4 years ago

IMO the article's conclusion is backwards. There's nothing wrong with symlinks when files are opened with openat(), since in principal the program (or controlling program) should always be in control of the filesystem layout. It's open() that causes problems, and complex interactions with symlinks in attacker-controlled directories are just one of them.

The POSIX file API was designed before the concept of capability passing (arguably, before the concept of computer security in general). A modern replacement would look more like Fuchsia, where child processes are provided file access scoped to their parent process's authority. This same scoping can also be used within a process, for example to implement a server that can "self-chroot".

  > So, more functions following the pattern of openat() had to be created
  > [...]
  > Some are still missing, like getxattrat() and setxattrat().

The functions to get/set xattrs on a file descriptor (rather than a path) are fgetxattr() and fsetxattr(). They're not usable for the specific case of a file descriptor opened with O_PATH, but that restriction is both documented and reasonable -- O_PATH doesn't allow operations that inspect the state of the file itself, such as reading/writing.

A better example might have been listxattr() vs flistxattr(), because the former works on a file without read permissions, but the latter fails on a descriptor opened with O_PATH.

  listxattr("xattr-chmod000.txt", NULL, 0)         = 14
  listxattr("xattr-chmod000.txt", "user.testattr\0", 14) = 14
  getxattr("xattr-chmod000.txt", "user.testattr", NULL, 0) = -1 EACCES (Permission denied)

  openat(AT_FDCWD, "xattr-chmod000.txt", O_RDONLY|O_PATH) = 3
  flistxattr(3, NULL, 0)                  = -1 EBADF (Bad file descriptor)

jerf• 4 years ago

"There's nothing wrong with symlinks when files are opened with openat(), since in principal the program (or controlling program) should always be in control of the filesystem layout. It's open() that causes problems, and complex interactions with symlinks in attacker-controlled directories are just one of them."

One of my minor annoyances with new languages is the continued persistence of open-based file APIs, with openat APIs shoved off to the side if they are even implemented at all. If you start from scratch with an openat-based API, it's not even that hard; you basically get a file object, just one with some different attributes and methods (or appropriate local ideas), most of which you don't care about, and it's not that hard to work with if you start with that from day one. It can be quite hard to backport something deeply based on string-based path manipulation into the *at-based APIs, though.

I haven't deeply studied it but you ought to be able to simulate an openat-based API on a conventional filesystem that doesn't support it. It may not immunize you to security issues, but at least the code ought to be as portable as any other code that starts getting detailed about its interactions with filesystems, which is already "kinda, not very, some elbow grease required"... it's not like the bar is sky high because all that stuff already works perfectly across all platforms and filesystems anyhow.

ziml774• 4 years ago

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 and npm packages: https://blogs.windows.com/windowsdeveloper/2016/12/02/symlin...

faragon2• 4 years ago

You could create symlinks since Windows Vista without permission elevation, if having disabled the UAC ("User Account Control").

ziml774• 4 years ago

Disabling UAC meant there was nowhere to elevate to because you just had admin rights all the time.

alerighi2• 4 years ago

There is an option (that is proposed when you install git) to allow normal users to create symlinks. The fact is that symlinks are very useful to a developer, and a lot of development tools make use of them.

kasabali2• 4 years ago

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...

ziml774• 4 years ago

Thanks for the correction. I actually think I did use this option way back, but just completely forgot about it.

mongol2• 4 years ago

"X is fundamentally broken" is a tired trope. To me, something is broken if it is no longer working as intended. It used to work, but now it does not - it is broken.

If something works as intended, but its utility is limited, and it can be improved, it is not broken.

joosters2• 4 years ago

Symlinks work as intended, but they cause a lot of unintended security vulnerabilities, i.e. they break lots of otherwise-functioning code.

You can play with your words and redefine their meanings, but the vulnerabilities remain.

mongol2• 4 years ago

They have been around for 40+ years, they don't break code unless we are talking about code predating their introduction. It is not me playing with words, I am just pointing out a tired trope.

rob_c9• 4 years ago

but they cause a lot of unintended security vulnerabilities

No, bad coders on UNIX platforms do this.

The code may be valid code, but if it's intending to support running on UNIX it should do it properly not assuming it's on a FAT32 filesystem in 2022.

Or, even better, run the code you don't trust on fat32 filesystems, see how far that gets.

pif• 4 years ago

they break lots of otherwise-functioning code.

There is no otherwise! POSIX has symbolic links: if your software does not function with symbolic links, it does not function on POSIX.

indymike• 4 years ago

You can play with your words and redefine their meanings, but the vulnerabilities remain.

I don't think OP was trying to play with words, I do think there's an absolute "this symlink thing is a vuln" vs an absolute "I use symlinks to make X work" argument. Symlinks have always been at the line between the absolutes. They do enable a great deal of functionality but they can be a security risk, and source of bugs when developers don't handle them correctly. That said, they are heavily used feature on unix like oses. My /usr/bin on Ubuntu has 48 of them (most were put there by apt installed packages).

littlestymaar• 4 years ago

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, but maybe one time every 20 or 30 years is OK…

SiempreViernes• 4 years ago

I take it that here "technology landscape" means something like "the gui portion of the software stack", right?

Beltalowda• 4 years ago

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.

Bridges and buildings from the 1970s (and much older) are still working fine today.

The thing is, if I do decide to replace my bridge or building because it's old and outdated then I can just replace that one thing without affecting much else. With computers, that is obviously not the case: you need to replace the entire city.

Plus, it's not really the case that we "keep using almost unmodified stuff from the 70s"; while many concepts remained the same and things remained compatible, things have been greatly extended and modified since; it's like those old buildings that were built during the middle ages (or sometimes even earlier) that have been changed and upgraded extensively throughout the centuries to the point you really need to know where to look to see it's actually a centuries-old building.

kllrnohj2• 4 years ago

I don't think that's entirely true. There's plenty of major systems that have made fundamentally incompatible breaking changes in order to move things forward. Windows did that with Vista, Android did that with Linux (eg, app sandboxing per UID, heavily restricted filesystem access to shared directories), etc..

It's kinda mainly desktop/server Linux where there's this inability to move forward.

toast0• 4 years ago

Internal plumbing is largely unchanged. Sure, there's more flexible pipe, and a lot more plastic pipe, and a lot more quarter turn valves, but thread pitch and pipe diameters are largely unchanged and unchangable.

umanwizard2• 4 years ago

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

3pt141592• 4 years ago

The word "broken" came from before we had constant arms races in technology. Obviously we don't call clubs broken because we now have rapid artillery, but there was enough time between clubs and swords, and swords and guns to allow transitions away.

When I'm exposed to a core OS feature I expect by default that it should not come with expected, critical security vulnerabilities. It is rational to expect a user to use the basic features of an OS and expect them not to cause severe issues. You can say it's not broken, and that's true in as much as they're still functional, but if by broken one means the larger question of "is this reliable and safe?" then I think the answer is pretty clear that symlinks are broken.

ploxiln2• 4 years ago

In the modern world, the demand seems to be that every tool be perfectly safe in every situation no matter what you do (and it seems practically nothing lives up to this demand, given the ever increasing river of silly CVEs for almost every component, like regex DoS on build tools).

It's important to understand the scope of the issue. If you create and operate on your own symlinks in your own folders, there is no problem. The problem is when a more privileged user operates on folders that can be written to by less privileged users, for example system daemons (like a /tmp cleanup, or a web server serving /home/*/www), or suid binaries. These things need to be written very carefully, it is now clear.

But if I'm working with my own files, media, source code, build tools, web pages, etc, in my own folders, then symlinks are still fine.

And there is an existing setting to mitigate a couple common forms of the issue that does exist when accessing folders other users can write to: https://www.kernel.org/doc/html/latest/admin-guide/sysctl/fs...

nine_k2• 4 years ago

If it used to work without letting others pwn your account or box, and not it fails to, it's broken.

rob_c9• 4 years ago

The trouble with symbolic links is users who don't understand/use linking coming from alternate platforms and developing on/for UNIX.

This is a feature in the same way that shellsock was used as a feature for many years by experts. Thankfully I'm expecting something like POSIX to save us this time.

shadowgovt2• 4 years ago

Don't hard links suffer from the issue that because they're actually links to a specific file, not path pointers, that you can replace the target file thinking you have updated something in the system and instead have stale hard links lying around, referencing the older version when you intended to replace the older version for all users?

I think that in a hypothetical world where symlinks worked like hard links, we'd be swapping out the security complaints in this post for articles about how hard it is to upgrade a POSIX system properly, tools and tricks you can use to make sure you truly replaced all instances of a binary with a known vulnerability, and so on.

jhallenworld4• 4 years ago

Hardlinks exist, so you already have this problem. Tar has to keep track of inode numbers to recreate hard links for example.

shadowgovt2• 4 years ago

What I mean is that it's pretty SOP to have a package that installs a new command to work by installing to /opt/my-package and then symlinking /usr/bin/my-cmd to /opt/my-package/my-cmd.

In the absence of symlinks, that link would be hard and dpkg et. al would have to do package management by deleting the /usr/bin/my-cmd link and re-creating it instead of letting it ride, trusting that it will point to the correct thing when the update completes because the target bin will have changed.

jhallenworld4• 4 years ago

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.

jmillikin2• 4 years ago

Whether directories can be hardlinked depends on the filesystem and OS. When macOS switched from HFS+ to APFS, one of the changes was that they dropped support for directory hardlinks.

https://developer.apple.com/library/archive/documentation/Fi...

jhallenworld4• 4 years ago

I'm not a macOS user, but these sure seem to add complexity:

https://stackoverflow.com/questions/80875/what-is-the-unix-c...

The filesystem has to check for and disallow loops.

nine_k2• 4 years ago

The GC algorithms for hardlinked directories can be the same as for harlinked files: reference counting.

jhallenworld4• 4 years ago

Only if there are no loops..

samatman• 4 years ago

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

kasabali2• 4 years ago

Tell that to btrfs :)

bhawks2• 4 years ago

A posix filesystem by itself is not a defensible security perimeter. Symlinks introduce security problems but there are other sources as well. If you have a system where processes with different trust profiles share a common view of a file system you have to assume one can manipulate the filesystem state to subvert the other.

Android has dealt with this via locking down and isolating apps to their own filesystems. Cross app communication and data sharing utilizes IPC primitives that have rich caller/Callie information that can be used to build capabilities and authn/authz checks.

The posix filesystem just doesn't have the abstractions/expressiveness one would need to build a robust security perimeter between untrusted apps.

philsnow• 4 years ago

The posix filesystem just doesn't have the abstractions/expressiveness one would need to build a robust security perimeter between untrusted apps.

This, absolutely, but I think it's even worse than that; in my mind the value prop of k8s is twofold: declarative configuration and isolation that forces apps to be able to interact over a very small boundary, the network overlay.

js24• 4 years ago

I'm sorry symlinks are a thorn in Jeremy's side, but they are useful from a user's perspective. Hard links don't fill the same need. You can't normally hard link directories. If a file has multiple links, finding them all normally requires scanning the entire file system, so deleting a file now becomes harder. A file with multiple links doesn't have an obvious canonical path.

As an example of all these issues, I manage a bunch of Mac build hosts with multiple Xcode versions installed. We only retain the most recent patch release of each major.minor version, but drop compatibility symlinks in place for the other versions. On macOS, an application is just a directory. So for example we'll have:

  Xcode-13.0.app -> Xcode-13.0.1.app
  Xcode-13.0.1.app

From a simple "ls" it's obvious which versions are installed and which are just compatibility shims. Symlinks are just so damn convenient for use cases like this. Hard links don't cut the mustard here.

So there are more reasons for symlinks than just "hard links are restricted to linking within the same filesystem", but yes, that too.

Probably I'm just lacking imagination and there's a solution that offers the advantages of symlinks with none of the downsides, but in my experience, we see this sort of indirection all over the computing landscape, so it seems like there's a fundamental need for it.

OnlyMortal2• 4 years ago

I take it an “alias” isn’t good in this case? An alias does follow a move of the original - usually.

yjftsjthsd-h• 4 years ago

Interesting; how does that work under the hood?

lxgr2• 4 years ago

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 system level? Just store a back pointer from a file to each of its names.

The fact that it's possible to break symlinks very easily by deleting the pointed-to file (name) is a problem as well: Wouldn't application developers usually, or at least sometimes, want to know about the fact that they are about to break a link (or conversely, not deleting the final copy of a file and not just a reference to it)?

So there are more reasons for symlinks than just "hard links are restricted to linking within the same filesystem"

I think this might be the only real (technical/historical) limitation. The rest could probably be worked around, but maybe having two distinct types of links, with these other binary decisions (allowing loops, making deletion explicit vs. a matter of referenc counting) being more or less arbitrarily bucketed into those two types based on what was easier to implement.

mzs• 4 years ago

ELOOP errno

XorNot2• 4 years ago

Hard links don't have a canonical name though - they're all equally the same file, and this is really a problem: opening and editing a file in one location, edits it in all of them without you knowing what those locations might be.

Symlinks at least explicitly declare the dependency and how it should mutate.

A classic being /etc/resolve.conf symlinks - if I'm untarring and restore a symlink for it, I'm currently saying the file should have content from somewhere else on the system - not that the file is specific content.

js24• 4 years ago

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 back pointer." That will obviously introduce its own set of complexities and trade-offs. Where do you store the pointers? What's the API for viewing them? What's the CLI for viewing them? Is it a new switch to `ls`? A new CLI entirely? How do you keep the pointers up to date? What sort of locking is needed when updating the pointers? What about `fsck`? How do you get this implemented across the multitude of Unix and Unix-like OS's and file systems?

(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.)

Again, I'm not saying there isn't a better solution, but I don't think it's patching up hard links. I think it's something outside the box of both hard links and symbolic links.

jandrese• 4 years ago

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.

lloeki• 4 years ago

> You can't normally hard link directories.
That's only to avoid loops, as far as I understand

Later HFS+ does support directory hard links, a feature introduced for Time Machine IIRC, but generally unavailable to the user.

kazinator5• 4 years ago

Symlink loops are handled in the pathname resolution function in the kernel. Too many indirections of symlinks (typically around forty or so?) result in the resolution bailing with an ELOOP errno.

inkyoto2• 4 years ago

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 inode and one or more directory entries pointing back to a specific block allocation via the associated inode. This makes hard links easily possible and very cheap. It is a one to many relationship (one block allocation to many directory entries), and turning it into a many to many relationship, with each directory entry pointing to every single possible permutation of other directory entries across the entire file system a nightmare in every imaginable way.

It is even possible to zero directory entries pointing to an inode (if you poke around with the file system debugger, you can manually delete the last remaining directory entry without releasing allocated blocks into the disk block pool but the next fsck run will reclaim them anyway).

waynesonfire• 4 years ago

symlinks are great, I don't see why we would remove such feature. The author pointed out a bunch of issues around atomic operations related to symlinks which in my view are valid. Similar TOCTOU race exists with PIDs, see https://lwn.net/Articles/773459/

Not sure whether the pid issue was ever resolved, havn't checked in on that in a while.

GoblinSlayer3• 4 years ago

https://man7.org/linux/man-pages/man2/pidfd_open.2.html

IshKebab3• 4 years ago

Symlinks are great from a "just make it work!" point of view but they're absolutely terrible from a "make it robust, sane and secure" point of view.

All of the points in the article are valid but there's even simpler stuff like the fact that you can't canonicalise paths (resolve ..) without reading the filesystem.

This should be required reading: https://9p.io/sys/doc/lexnames.html

cosmiccatnap• 4 years ago

Features add complexity and robust features add robust complexity. Robust features that span a core component like filesystem handling span many utilities.

Maybe we should do the same search on samba vulnerabilities have have him take a look in the mirror...

stjohnswarts• 4 years ago

Does anyone else read something like this

Jeremy Allison gave a talk titled "The UNIX Filesystem API is profoundly broken: What to do about it?".

and immediately shut down on the person saying it because he all know it's extremely hyperbolic given what is happening in reality?

It's great to not like something and point out its flaws as far as you use them and "here's the great idea to fix those issues" but to try to offend you audience and the Unix community as the first words you see in a talk is a great way to have people shut off and think "oh great another neckbeard with an overinflated sense of self"

marcosdumay• 4 years ago

I really think that an "open the file as this user or group (also constrained to the current user's permissions)" option will solve the security problems better than the "open the file relative to this root" one. Or, failing that, an usable capability system (not SELinux).

I don't think just checking for symlinks really solves anything. It may make your bugs harder to exploit, what is always good, but people use symlinks, so you have to support them, so the bugs will stay there.

forrestthewoods• 4 years ago

Hard linking files isn’t useful in my experience because it requires every tool working with that file to never delete it and recreate it. However that’s what exactly many tools do. So the only way to reliably “share” a file is with a symlink. At least this is true for my workflows.

alerighi2• 4 years ago

Well there is the solution: work with file descriptors and not with paths. POSIX should be extended to make sure all functions that take a path has also the version that takes the file descriptor (to avoid the /proc/self/fd/%d hack, that is not portable to non-Linux OS that don't have /proc, and on Linux requires /proc to be mounted that is not always the case for example in sandboxes and chroots).

You don't also only have problem with symlinks if you work with paths, but with any kind of paths. For example is wrong to check with the path if a file exists and then do something with it, because it can as well be deleted, modified, etc. You have to work with file descriptors, and use only one function (open) to resolve the path into a descriptor one time (that is also more efficient, since resolving a path is computationally expensive, especially on modern filesystems).

kazinator5• 4 years ago

An application running as root may try to check that /data/mydir is a regular directory (not a symlink) before opening the file /data/mydir/passwd. In between the time the program does the directory check and the file open, an attacker could replace the mydir directory with a symlink to /etc, and now the file opened is, unexpectedly, /etc/passwd. This is a kind of race condition known as a time-of-check-to-time-of-use (TOCTOU) race.

That application is doing the wrong check; it should be validating that every component of the path is a directory which is only writable to root.

First you stat("/"). OK, that is a directory and writable only to root: so no non-root process can put a symlink there. Next we check "/data". OK, that's a directory, and since we know / is owned by root and not world-writable, /data cannot be replaced by a symlink.

And so on ...

This can easily be made into a function like safe_path("/data/dir/path/to/mypasswd") which returns true only if no pathname component is something which a user other than the caller, or root, could tamper with to point to a different file.

The open system call should have a flag for this, O_SAFE. That would alter the behavior of the name resolution function (traditionally, "namei") to do these checks along the path.

The path could have symlinks, if they are not tamperable from the POV of the calling user.

Typically superuser applications in Unix rely on filesystem structure. They set environment variables like PATH carefully, and stick to accessing data in known directories that had better be safe. If /data/mydir/passwd is something that is manipulated by a root application, then the system is misconfigured if any of these is writable to a non-root user: /, /data, /data/mydir or /data/mydir/passwd.

If that is the case, you don't need symlinks to wreak havoc on the application. You can, for instance, write your own password into that password file and then falsely authenticate with that app.

yyyk2• 4 years ago

No, there is absolutely nothing broken about symbolic links. What is the issue here is accessing user files as root. That is inherently unsafe in POSIX and also affects hardlinks as well (even more so, since you have to "follow" hardlinks http://michael.orlitzky.com/articles/posix_hardlink_heartach...).

partialzero• 4 years ago

Maybe I'm being naive, but I don't get how "pathnames as a concept are now utterly broken in POSIX". Isn't this "merely" a problem that the resolution of the path name is dynamic and can change between inspection and use? Wouldn't a practice of resolving pathnames once (recursively, atomically, whatever) into an immutable, opaque, direct handle, such as file descriptor, before use solve this issue? I realize what I just said may be tantamount to "all file io ops taking path strings are broken" - but that seems like a problem with the initial API design, not with the concept of having a level of indirection in path name resolution itself.

bityard• 4 years ago

This is basically what I was going to say. The article spends a lot of time arguing that TOCTOU patterns introduce security vulnerabilities, which I think all programmers (should!) already know but then comes to the weird conclusion that we'd just be better off without symlinks instead of designing an API to work with them atomically.

Kinda reminds me of how a lot of UX changes happen: "This really popular feature is a bit kludgy and hard to maintain, let's just rewrite the whole app without it! (Instead of doing the work required to make it not suck.)"

drdec• 4 years ago

Almost all the TOCTOU examples given in the article could be modified not to involve symlinks and still be valid.

GoblinSlayer3• 4 years ago

Clients that have write access to the exported part of the file system under a share via SMB1 unix extensions or NFS can create symlinks that

So, it's not symlinks broken, but SMB1 unix extensions broken when exposed to the world for symlink creation. AIU this features doesn't even serve windows interoperability. And if the author wanted to disable all symlinks altogether, what is the purpose of these extensions?

amluto• 4 years ago

I personally think that hard links should go away. I have trouble thinking of any use for hard links that isn’t better served by CoW links. Hard links have quite surprising properties with respect to chmod, they are awkward to handle in archival tools, and even reliably identifying them is awkward to impossible in general.

cryptonector• 4 years ago

The problem here is Linux.

bartimus2• 4 years ago

I was copying a file today and thought: "Why is it duplicating the data? Why does it not just create a new second filename pointer in the filesystem?"

WhatIsDukkha• 4 years ago

Take a look at the cp man page -

https://www.man7.org/linux/man-pages/man1/cp.1.html

Look for "reflink" and you get your wish :)

bartimus2• 4 years ago

Very cool! :)

jwilk• 4 years ago

FICLONE is the underlying ioctl:

https://www.man7.org/linux/man-pages/man2/ioctl_ficlone.2.ht...

As of Linux 5.18, it's supported by btrfs, xfs, overlayfs and some networking filesystems.

kazinator5• 4 years ago

Response in code: https://news.ycombinator.com/item?id=32201150

The trouble with symbolic links

Related Stories