RE: Request for feedback: Filesystem API

On Aug 13, 2013 7:32 PM, "Domenic Denicola" <domenic@domenicdenicola.com>
wrote:
>
>  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.

The primitives are all there. To implement move across filesystems you
would simply use createFile/copy and remove/removeDeep.

I'm not quite sure I understand what implementation of move() that you are
arguing for?

Are you arguing for a move-that-works and deals with non-atomic moves
internally? Or are you arguing for a move that fails when used across
filesystems and which would require moveAnyWhichway to be implemented using
a JS library?

/ Jonas