Re: [libvirt] [PATCH 03/18] Introduce a virFileDeleteTree method

On 04/04/2013 07:40 AM, Daniel P. Berrange wrote: Don't we already have something like this? /me goes and looks... yep, very similar to virCgroupRemoveRecursively - hopefully a later patch drops that function to use this instead. I like the idea of a generalized interface. We should use gnulib's LGPL unlinkat. On capable kernels, it avoids O(n^2) behavior that is inherent in computing filenames in a deep hierarchy. On less capable kernels, it still makes this code simpler to write (no virAsprintf needed here). Potentially wasteful on systems like Linux that have d_type. If d_type exists, and is not DT_UNKNOWN, then the difference between DT_DIR and other types can save some system call efforts. Potential TOCTTOU race. POSIX allows unlink("dir") to succeed (although most platforms reject it, either always [Linux], or based on capabilities [Solaris, which also has code to give up that capability, and where gnulib also exposes that]). If we ever manage to unlink() a directory, because we lost the TOCTTOU race, then we have done bad things to the file system. But you are guaranteed that rmdir() on a non-directory will gracefully fail; so you can minimize the race window by attempting to treat _every_ name as a directory first, then gracefully fall back to unlink() if the opendir() fails with ENOTDIR, without ever having to waste time lstat()ing things. Hmm, except that you don't want to follow symlinks, but opendir() follows them by default; so you would have to use open(O_DIRECTORY)/fdopendir() instead of raw opendir(). What happens on files that have restrictive permissions? Do we need to worry about chmod()ing files (or containing directories) to give ourselves enough access so that we can then turn around and unlink() files regardless of restrictive permissions? What you have works, even if it is inherently quadratic compared to using unlinkat(). What sort of trees do we envision deleting? Do we need to start worrying about performance, using lessons learned from GNU coreutils? Or are the trees small enough, with properties of never being too-restrictive in file mode, and where the trees we are deleting are unlikely to be hit by a malicious user exploiting a TOCTTOU race, that we can just stick with this implementation as-is? Very weak ACK, depending on what you answer to my commentary. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org