Applications increasingly need to present several AsyncVFS backends through one namespace—for example memory/OPFS content, Taildrop, WebDAV, FTP, SFTP, and SMB shares. Without a package-owned composite, each application must implement path routing, synthetic directory entries, cross-backend operations, capability negotiation, and error handling itself.
Requested direction
Add a composite or merged AsyncVFS implementation to @webnet/vfs.
The initial design should explicitly choose and document its namespace model. A mount-table model is the safest baseline:
mount independent VFS instances at normalized paths;
expose synthetic ancestor directories and merge their entries with backend entries;
route operations to the longest matching mount;
prevent .. and normalization from escaping or bypassing a mount;
support dynamic or immutable mount configuration.
If overlay semantics—multiple backends at the same path with precedence and copy-up—are desired, treat those as an explicit additional policy rather than an accidental consequence of iteration order.
Operations and capabilities
Specify:
stat/readdir behavior at root, synthetic ancestors, mount points, and collisions;
same-backend versus cross-backend copy/move;
whether cross-backend operations use the standard shims;
write routing and read-only mounts;
propagation of optional capabilities and runtime unimplemented errors;
mount lifecycle, backend shutdown, and failures from one backend;
stable path/name rewriting in returned Stat values;
behavior when a mount disappears during an open stream.
Use the canonical path utilities tracked in #78 and the optional-operation/error model tracked in the companion VFS issue. Add composite-specific tests plus the common AsyncVFS conformance suite from #80.
This is a larger follow-up and should start only after the current filesystem protocol PRs have merged.
## Motivation
Applications increasingly need to present several `AsyncVFS` backends through one namespace—for example memory/OPFS content, Taildrop, WebDAV, FTP, SFTP, and SMB shares. Without a package-owned composite, each application must implement path routing, synthetic directory entries, cross-backend operations, capability negotiation, and error handling itself.
## Requested direction
Add a composite or merged `AsyncVFS` implementation to `@webnet/vfs`.
The initial design should explicitly choose and document its namespace model. A mount-table model is the safest baseline:
- mount independent VFS instances at normalized paths;
- expose synthetic ancestor directories and merge their entries with backend entries;
- route operations to the longest matching mount;
- prevent `..` and normalization from escaping or bypassing a mount;
- support dynamic or immutable mount configuration.
If overlay semantics—multiple backends at the same path with precedence and copy-up—are desired, treat those as an explicit additional policy rather than an accidental consequence of iteration order.
## Operations and capabilities
Specify:
- stat/readdir behavior at root, synthetic ancestors, mount points, and collisions;
- same-backend versus cross-backend copy/move;
- whether cross-backend operations use the standard shims;
- write routing and read-only mounts;
- propagation of optional capabilities and runtime `unimplemented` errors;
- mount lifecycle, backend shutdown, and failures from one backend;
- stable path/name rewriting in returned `Stat` values;
- behavior when a mount disappears during an open stream.
Use the canonical path utilities tracked in #78 and the optional-operation/error model tracked in the companion VFS issue. Add composite-specific tests plus the common `AsyncVFS` conformance suite from #80.
This is a larger follow-up and should start only after the current filesystem protocol PRs have merged.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Motivation
Applications increasingly need to present several
AsyncVFSbackends through one namespace—for example memory/OPFS content, Taildrop, WebDAV, FTP, SFTP, and SMB shares. Without a package-owned composite, each application must implement path routing, synthetic directory entries, cross-backend operations, capability negotiation, and error handling itself.Requested direction
Add a composite or merged
AsyncVFSimplementation to@webnet/vfs.The initial design should explicitly choose and document its namespace model. A mount-table model is the safest baseline:
..and normalization from escaping or bypassing a mount;If overlay semantics—multiple backends at the same path with precedence and copy-up—are desired, treat those as an explicit additional policy rather than an accidental consequence of iteration order.
Operations and capabilities
Specify:
unimplementederrors;Statvalues;Use the canonical path utilities tracked in #78 and the optional-operation/error model tracked in the companion VFS issue. Add composite-specific tests plus the common
AsyncVFSconformance suite from #80.This is a larger follow-up and should start only after the current filesystem protocol PRs have merged.