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: Tue, 20 Aug 2013 00:03:10 -0700
Message-ID: <521314AE.1030704@secure.meer.net>
To: Jonas Sicking <jonas@sicking.cc>
CC: Domenic Denicola <domenic@domenicdenicola.com>, public-script-coord@w3.org
Jonas Sicking wrote:
> >> 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.

This is a footgun.

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

Unix had directory removal at user-level initially, but moved to 
rmdir(2) which can fail with ENOTEMPTY, to avoid the footgun (also to 
abstract at the kernel boundary over future directory entry 
representations, but that could've been done in libc code).

Here I will join Allen in pointing to Unix history. It is best to have 
rm -r (removeDeep) be the composite operation (enumerateDeep + remove) 
and remove the primitive (which fails on a non-empty directory).

Received on Tuesday, 20 August 2013 07:03:39 UTC

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