- From: Brendan Eich <brendan@secure.meer.net>
- Date: Tue, 20 Aug 2013 00:03:10 -0700
- 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). /be
Received on Tuesday, 20 August 2013 07:03:39 UTC