Fixes rm -r (XCC)
authorBarret Rhoden <brho@cs.berkeley.edu>
Wed, 18 Jun 2014 18:50:49 +0000 (11:50 -0700)
committerBarret Rhoden <brho@cs.berkeley.edu>
Wed, 18 Jun 2014 18:50:49 +0000 (11:50 -0700)
The root of the issue is the use of successive readdirs concurrent with
modifications of the underlying directory.  Coreutils's rm handles this
(via the fts_ family of functions) by reading in the entire directory
before removing.  So I'll stick with the current behavoir: if you do
that, unexpected things will happen, and just have busybox rewind after
each rm.

You'll need to rebuild glibc, after copying over the new file.

You'll also need to rebuild busybox, after applying the patch.

tools/compilers/gcc-glibc/glibc-2.14.1-ros/sysdeps/ros/rewinddir.c [new file with mode: 0644]
tools/patches/busybox/busybox-rm-rewinddir.patch [new file with mode: 0644]

diff --git a/tools/compilers/gcc-glibc/glibc-2.14.1-ros/sysdeps/ros/rewinddir.c b/tools/compilers/gcc-glibc/glibc-2.14.1-ros/sysdeps/ros/rewinddir.c
new file mode 100644 (file)
index 0000000..2467fac
--- /dev/null
@@ -0,0 +1 @@
+#include <sysdeps/unix/rewinddir.c>
diff --git a/tools/patches/busybox/busybox-rm-rewinddir.patch b/tools/patches/busybox/busybox-rm-rewinddir.patch
new file mode 100644 (file)
index 0000000..5828927
--- /dev/null
@@ -0,0 +1,10 @@
+--- a/libbb/remove_file.c      2014-06-18 11:44:05.962239038 -0700
++++ b/libbb/remove_file.c      2014-06-18 11:44:11.331956241 -0700
+@@ -59,6 +59,7 @@
+                               continue;
+                       if (remove_file(new_path, flags) < 0)
+                               status = -1;
++                      rewinddir(dp);
+                       free(new_path);
+               }