|
|
Subscribe / Log in / New account

Unioning file systems: Architecture, features, and design choices

Unioning file systems: Architecture, features, and design choices

Posted Jan 15, 2013 15:00 UTC (Tue) by hummassa (subscriber, #307)
In reply to: Unioning file systems: Architecture, features, and design choices by nix
Parent article: Unioning file systems: Architecture, features, and design choices

> A nastier question is what rm -r does in the context of such links.

Exactly what it does in the case of a union fs: removes all files, recursively, from the "top" filesystem (the "bottom" filesystems are read-only), refusing to remove any files present in the "bottom" filesystems.

> A really nasty question is what wildcard expansion does: what does /c/f* do if there are files matching f* in both /a and /b? As far as I can see, the semantics sunburnt described do not allow for the obvious semantics (expand files in /a and /b) without less-than-obvious changes to every program that does globbing and fnmatching everywhere -- and without those changes, the semantics you seem likely to get are quite bizarre.

Again, no nasty question: /c/f* will bring all files that match in the union /c, i.e., a merge with of /a/f* and /b/f*. A file called f1 present both in /a and in /b will come only once, referring obviously to /a/f1.


to post comments

Unioning file systems: Architecture, features, and design choices

Posted Jan 15, 2013 23:50 UTC (Tue) by nix (subscriber, #2304) [Link]

OK, it sounds like rm will need explicit support for this, then. The semantics you describe certainly don't fall naturally out of the readdir() semantics you suggest.


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