- From: Brendan Eich <brendan@secure.meer.net>
- Date: Wed, 14 Aug 2013 14:18:41 +1200
- To: Jonas Sicking <jonas@sicking.cc>
- CC: Domenic Denicola <domenic@domenicdenicola.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
Jonas Sicking wrote: > On Sat, Aug 10, 2013 at 5:57 PM, Domenic Denicola > <domenic@domenicdenicola.com> wrote: >> From: Jonas Sicking [mailto:jonas@sicking.cc] >> >>> Like Brendan points out, what is considered the "low-level capabilities" isn't always obvious. >> I think a good guide is whether it's "atomic" or not. As such "move" is definitely atomic, whereas the others are not as much, so my apologies for including it there. A new concern, which this time I'll phrase as a question---is moving, or removing, a directory atomic? > > remove() and removeDeep() are definitely atomic. Just to be sure: remove on a directory fails, removeDeep is required? E.g., remove is rm, removeDeep is rm -r (not just rmdir)? Or does remove on an empty directory succeed too? remove : removeDeep :: (rm or rmdir) :: rm -r. > 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? > For copy() we probably wouldn't write guarantees into the spec. But I > would push for making it atomic in the Firefox implementation as often > as possible since it'll reduce the risk of website bugs. How can copy be atomic on any block- or TCP-segment-bounded medium? If a large copy fails in the middle (device hard-crashes), then you'll have a partial copy on the destination side. Contrast to same-device rename(2), which really is atomic-as-in-crashproof. Either it fails or it succeeds, no partial results. > I don't see how we could make either enumerateDeep() or enumerate() atomic? No more than you could read :-P. /be
Received on Wednesday, 14 August 2013 02:19:10 UTC