W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2013

RE: Request for feedback: Filesystem API

From: Domenic Denicola <domenic@domenicdenicola.com>
Date: Wed, 14 Aug 2013 02:31:34 +0000
To: Brendan Eich <brendan@secure.meer.net>, Jonas Sicking <jonas@sicking.cc>
CC: "public-script-coord@w3.org" <public-script-coord@w3.org>
Message-ID: <B4AE8F4E86E26C47AC407D49872F6F9F8D8B5567@BY2PRD0510MB354.namprd05.prod.outlook.com>
 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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:50 UTC