|
|
Subscribe / Log in / New account

When and why to deprecate filesystems

When and why to deprecate filesystems

Posted Mar 8, 2022 22:42 UTC (Tue) by NYKevin (subscriber, #129325)
In reply to: When and why to deprecate filesystems by pabs
Parent article: When and why to deprecate filesystems

> Options to ignore certain features could be added.

The problem is that, in practice, either it errors out every time a feature can't be copied and wasn't explicitly excluded, or else it silently swallows the error and loses your data. That might not sound so bad, until you realize that you're going to lose a lot of rather basic information in some cases; FAT in particular is extremely lossy, and will lose symlinks (and everything else that is not a "regular file" or directory), (probably) simple permissions, and almost certainly all forms of "extended" attributes such as ACLs. I also don't believe it supports hard links, and some particularly old versions don't even support subdirectories.

> A recursive option could let the kernel know that yes you want that link.

This opens up an enormous can of worms. What happens if the process receives a signal while it's inside a recursive kernelspace copy operation? Does the whole operation fail with EINTR, and you have to start over from scratch? What happens if file #2,758 can't be copied, do you just return EIO and make the application deal with it? More generally, how do you handle exceptional circumstances while the copy is taking place?


to post comments


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