Re: Request for feedback: Filesystem API

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