Re: Request for feedback: Filesystem API

On Aug 13, 2013 7:18 PM, "Brendan Eich" <brendan@secure.meer.net> wrote:
>
> 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)?

Yes, I think that is correct. I think I got that wrong elsewhere in this
thread, but what you are saying I think is the expected behavior.

My preferred solution is to get rid of remove() and allow removeDeep() to
work on both files and directories.

I think protection of accidentally removing a non-empty directory belongs
in UI and not in API (Unix commands land somewhere in between)

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

Good point about crashes. We indeed can't protect against that. At least
not without a more effort than I think we'd be willing to invest for now.
(Journals could be kept separate from backend and partial copy be removed
on restart)

The best we could reasonably do is to prevent other access from web pages
to the partially copied directories while the copy is still in progress.

I don't think either of these things is something we would do in the
initial implementation. We would simply let copy() be non-atomic.

I agree that could be an argument for not keeping copy().

/ Jonas