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: Mon, 19 Aug 2013 13:07:29 -0700
Message-ID: <CA+c2ei8Ay55R0NZeoSz84EYbjYRzTOKnXV9YM2Q-ShHBOfz_Tg@mail.gmail.com>
To: François REMY <francois.remy.dev@outlook.com>
Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>, Brendan Eich <brendan@secure.meer.net>, Domenic Denicola <domenic@domenicdenicola.com>
On Mon, Aug 19, 2013 at 10:55 AM, François REMY
<francois.remy.dev@outlook.com> wrote:

> Your proposal simply does not provide a sufficient amount of primitive to handle this *basic* deep copy scenario right. I dare you proposing a code that does allow something even close to that.

I think this cuts to the core of your argument. My vision was to have
a low-level API. Like you say, conflict resolution can be handled so
many ways so I think it's best handled by libraries or by
application-level logic.

An API like what you are proposing is certainly very interesting, but
it's something that I think should be written as a library on top of
the low-level API provided by the platform.

But like you point out, in order to let applications/libraries handle
this, we need the correct primitives in the platform API.

My hope was that you could use enumerate() recursively to enumerate
the source tree. For each found file/directory use
createFile()/createDirectory() to create entries in the target tree.
If this fails with a "already exists" error then you can handle the
error in whatever way you want and then keep enumerating once
appropriate.

We'll definitely try to write some code to test this out once we have
a better understanding of what the "EventStream" (aka "async iterator"
aka "cursor") looks like.

It would be cool though to find a way to support this without
requiring the use of recursive enumerate() calls, since async
recursive code is not that pretty. enumerateDeep() almost takes care
of this, except that enumerateDeep() only returns Files which means
that it misses empty directories.

I haven't found a way to change enumerateDeep() such that it also
exposes empty directories without creating an API that is too messy.
Suggestions encouraged!

> What about someone trying to delete a file that is currently in use?

This is a good question. One that applies for for multi-file
operations as well as the simple remove()/removeDeep() primitives.

Whatever we do for the remove()/removeDeep() primitive, I propose that
we do for non-atomic-move()s.

> If FileSystem-related operations were really that simple, they would not be worth multiple blog posts on the Windows 8 Engineering blog many years after they originally were introduced in Windows [1][2] nor would people use specific syncing software like FileZilla (that allows you to resolve conflicts to "do not copy in case of conflicts if some metadata matches) over an FTP connection to save bandwidth, nor would the "cp" command on linux have dozens of available flags [3].
>
> [1] http://blogs.msdn.com/b/b8/archive/2011/08/23/improving-our-file-management-basics-copy-move-rename-and-delete.aspx
> [2] http://blogs.msdn.com/b/b8/archive/2011/08/26/designing-the-windows-8-file-name-collision-experience.aspx
> [3] http://linux.die.net/man/1/cp

The windows articles here are all about UI. The linux link is about a
high-level API. None of this is about the low-level API that the OS
provides.

/ Jonas
Received on Monday, 19 August 2013 20:08:29 UTC

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