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

Re: Request for feedback: Filesystem API

From: Brendan Eich <brendan@secure.meer.net>
Date: Mon, 12 Aug 2013 11:05:51 +1200
Message-ID: <520818CF.2080706@secure.meer.net>
To: Domenic Denicola <domenic@domenicdenicola.com>
CC: Jonas Sicking <jonas@sicking.cc>, "public-script-coord@w3.org" <public-script-coord@w3.org>
Domenic Denicola wrote:
> A new concern, which this time I'll phrase as a question---is moving, or removing, a directory atomic?

Atomic, and idempotent (at most once). This was an issue with NFS in the 
past. Its "stateless" simplicity was a bit of a fraud, given the need 
for an "idempotency cache" in the server to avoid retransmitted unlink 
(remove) operations.

Unix semantics should mean unlinking a node (leaf file, regular or 
special; directory) is atomic and idempotent. Do we care about other 
filesystems' semantics? Allen invoked POSIX and I mentioned Unix as OS 
category-killer status, so I hope not!

Someone mentioned corruption later. This is not supposed to be visible 
to usercode. Of course, it happens. I lost part of the original 
SpiderMonkey RegExp implementation in 1997 (jsregexp.c) due to a bug in 
SGI's EFS, and recovered by writing a Boyer-Moore search program in C 
using ed on my init 1 (single-user) booted system, essentially grepping 
the block device and saving pieces of the file.

But replay of atomic-and-idempotent operations, and arrant data 
corruption, are layering violation bugs. Bugs should not inform our 
filesystem abstraction's design if we can help it. Unless we are putting 
it on the consumers of the API to do forward error correction!

Received on Sunday, 11 August 2013 23:06:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:17 UTC