Unable to remove directories with mtree -r
Closed this issue · 7 comments
I was experimenting with build systems and trying to employ mtree as a means to restore build trees back to their original state. This proof of concept was working quite nicely until encountering an unwanted directory tree which contained various files and other directories.
Here is a short demonstration of the issue:
% ~/t ll
total 0
drwxr-xr-x 1 earnest users 0 May 2 15:13 directory1/
-rw-r--r-- 1 earnest users 0 May 2 15:14 file1
-rw-r--r-- 1 earnest users 0 May 2 15:14 file2
% ~/t mtree -Pck sha256digest > mtree
% ~/t > unwanted_file
% ~/t mtree -r < mtree
...
unwanted_file extra, removed
% ~/t mkdir unwanted_directory/with/nested/content
mkdir: created directory 'unwanted_directory'
mkdir: created directory 'unwanted_directory/with'
mkdir: created directory 'unwanted_directory/with/nested'
mkdir: created directory 'unwanted_directory/with/nested/content'
% ~/t mtree -r < mtree
unwanted_directory extra, not removed: Directory not empty
I assume this is a known limitation and so I'm more hoping that there's also a known workaround without resorting to parsing the output.
Ideally I would like mtree -r ... to recursively remove the new parent directory instead of failing to do anything because it is not empty.
I think the thing to do here would be to add a new flag that means "recursively delete directories".
This would be backward-compatible.
Perhaps -R? It has typically been used in some (GNU) tools to signify a different kind of -r, typically meaning it follows symlinks.
Such a change would be welcome but as this is a port I'm not sure how you feel about keeping parity with FreeBSD's mtree source. Maybe FreeBSD could be convinced to add this feature themselves first?
Might be worth asking them. BTW -R is already taken :)
What does -R do? It's not documented in the manual...?
mtree: invalid option -- 'R'
usage: mtree [-LPUcdeinqruxw] [-f spec] [-K key] [-k key] [-p path] [-s seed]
[-X excludes]
It's implemented in FreeBSD's current version of mtree.
Ah, sorry. I should have checked that first; is this port tracking FreeBSD or OpenBSD's mtree?
If -R is taken then only [AaBGgHhJoQTVvwYyZz] are available (and [0-9]).
Fixed in 4f3e901.