RE: Request for feedback: Filesystem API

 From: Brendan Eich [mailto:brendan@secure.meer.net]
 
> > move() is atomic within the same filesystem. If we grow multiple
> > filesystem API backends in addition to the per-origin sandboxed one,
> > such as sd-card, system "pictures folder" and server-backed remote
> > folders, we probably can't guarantee atomicness when moving between
> > different backends. All of these backends exist in existing
> > browser-like implementations FWIW.
> 
> So long as the same-filesystem move is atomic, we need it as a primitive. The
> design choice cross-filesystem is whether it fails, or turns into non-atomic
> copy/remove. Unix rename(2) fails with EXDEV, the conservative/primitive
> choice. Then extendthewebforward fans can build the copy/remove non-
> primitive on top.
> 
> Or... rebuilding a higher-level moveAnyWhichway on top of such a move is
> tedious and unwanted -- we don't have the analogue of mv(1) to rename(2),
> the shell to the kernel. Developers just want a move than works in both
> cases, atomic or not.
> 
> If that's the case (and I suspect it is), then the reasoning from atomicity still
> helps: we must have move in the minimal standard in any scenario.
> 
> Domenic, what do you think?

I certainly agree that since same-filesystem move is atomic it should be there. I also agree that developers probably want move-that-works more than anything.

As such I would like to see moveAnyWhichway prototyped (and preferably specced) in JavaScript on top of move + whatever primitives are necessary for it. If we are missing primitives to create such an operation then we need to add them. Finding such primitives would be a big win IMO.

Once we have a working prototype then it should be included in the spec, preferably at the same time cross-file system stuff is introduced, so that once developers start working cross-filesystem they already have a move-that-works handy, and never have to worry about writing moveAnyWhichway themselves.

Received on Wednesday, 14 August 2013 02:32:26 UTC