- 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>
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