W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2013

RE: Request for feedback: Filesystem API

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 14 Aug 2013 00:37:43 -0700
Message-ID: <CA+c2ei90Gqf=JwKoEU9BdGt95AhZH920bK0YnRsqSV=sTEjM6A@mail.gmail.com>
To: Domenic Denicola <domenic@domenicdenicola.com>
Cc: Brendan Eich <brendan@secure.meer.net>, public-script-coord@w3.org
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
Received on Wednesday, 14 August 2013 07:38:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:50 UTC