bug#21084: rm appears to no longer be POSIX compliant (as of 2013 edition) re: deleting empty dirs and files under <path>/.

[Linda Walsh]

Paul Eggert wrote:
> Linda Walsh wrote:
> > > time rm -fr .
> > 183.23sec 0.69usr 36.25sys (20.16% cpu)
> > > time find . ! -name . -prune -exec rm -fr {} +
> > 219.58sec 0.87usr 40.81sys (18.98% cpu) -- about 36 seconds (~20%) longer
>
> Benchmarks like this are often suspect since a lot of it depends on 
> factors that are hard to reproduce.  That being said, when I tried a 
> similar benchmark on my machine, the 'find' solution was over 30% 
---
Did you run them on separate partitions over the same file-structure?

Neither rm nor find had a hot or even warm cache, as I mounted the file
systems just for this test.

You can use the same partitions/files, if you use dropcaches:
#!/bin/bash 

function dropcaches () {
 echo -n "3"|sudo dd status=none of=/proc/sys/vm/drop_caches
}

#if [[ address@hidden == 0 ]]; then 
 time dropcaches
#fi
-------------
If you run it, it runs the function then, if you source it, 
you'd have to insert 'time' manually later --- which I
usually do, as I like to know how long things take. 

Have had it take as long as over 60 seconds on my system,
though more often under 10.




> faster.  In any event the minor performance improvements we're talking 
> about would not be a compelling argument for adding UI complexity to 
> 'rm', even if the 'rm' approach was uniformly faster
---
        I was addressing Bernhard's explicitly stated concerns.
They were not my concerns.  


> > But you also didn't address points (3), (4) or (5)..
>
> They aren't a problem either.  As I mentioned, the "find" approach 
> conforms to POSIX and so is quite portable; that covers (3).
---
	You can't believe that. People with older systems don't 
always keep upto-date with the latest versions -- and likely
wrote most of their maint-scripts under the original POSIX 
charter.  They won't know until they are bitten and complain
alot louder than I'm comfortable with.

	It doesn't solve '4', since it's about users wanting 
similar behaviors not only in other packages, but within the
same package.  It's a broken wart that is not restricted in 
other utils -- and causes you to have to defend "one-file-system"
no longer being usable because the users should have known.

It would handle (5), _probably_.

But allowing dir/. would not cause the same problems a complete 
ban has, nor is it a likely candidate for abuse or accident.



Can you think of anything I've suggested that you've 
been supportive on, yet I know I