FASTRM(1)FASTRM(1)NAMEfastrm - quickly remove a set of files
SYNOPSISfastrm [ -d ] [ -e ] [ -uN ] [ -sM ] [ -cI ] base_directory
Fastrm reads a list of files, one per line, from its standard input and
removes them. If a file is not an absolute pathname, it is taken rela‐
tive to the directory specified on the command line. The base_direc‐
tory parameter must be a simple absolute pathname — that is, it must
not contain any ``/./'' or ``/../'' references.
Fastrm is designed to be faster than the typical ``| xargs rm'' pipe‐
line. For example, fastrm will usually chdir(2) into a directory
before removing files from it. If the input is sorted, this means that
most files to be removed will be simple names.
Fastrm assumes that its input is valid and that it is safe to just do
an unlink(2) call for each item to be removed. As a safety measure, if
fastrm is run by root it will first stat(2) the item to make sure that
it is not a directory before unlinking it.
If the ``-d'' flag is used then no files are removed. Instead a list
of the files to be removed, in debug form, is printed on the standard
output. Each line contains either the current directory of fastrm at
the time it would do the unlink, and then the path name it would pass
to unlink(2) as two fields separated by white space and a ``/'', or the
absolute path name (a single field) of files it would unlink using the
absolute path name.
If the ``-e'' flag is used, fastrm will treat an empty input file
(stdin) as an error. This is most useful when fastrm is last in a
pipeline after a preceding sort(1) as if the sort fails, there will
usually be no output to become input of fastrm.
If the ``-u'' flag is used, then fastrm makes further assumptions about
its work environment; in particular, that there are no symbolic links
in the target tree. This flag also suggests that it is probably faster
to reference the path ``../../../'' rather than start from the root and
come down. (Note that this probably isn't true on systems that have a
namei cache, which usually holds everything except ``..''). The
optional N is an integer that specifies the maximum number of ``..''
segments to use — paths that would use more than this use the absolute
path name (from the root) instead. If the ``-u'' flag is given without
a value, ``-u1'' is assumed.
If the ``-s'' flag is used, then fastrm will perform the unlinks from
one directory — that is when a group of files in one directory appear
in the input consecutively — in the order that the files appear in the
directory from which they are to be removed. The intent of this flag
is that on systems that have a per-process directory cache, finding
files in the directory should be faster. It can have smaller benefits
on other systems. The optional M is an integer that specifies the num‐
ber of files that must be going to be removed from one directory before
the files will be ordered. If the ``-s'' flag is given without a
value, ``-s5'' is assumed. When the directory reordering is in use
fastrm will avoid attempting to unlink files that it can't see in the
directory, which can speed it appreciably when many of the file names
have already been removed.
The ``-c'' flag may be given to instruct fastrm when it should
chdir(2). If the number of files to be unlinked from a directory is at
least I then fastrm will chdir and unlink the files from in the direc‐
tory. Otherwise it will build a path relative to its current direc‐
tory. If ``-c'' is given without the optional integer I then ``-c1''
is assumed, which will cause fastrm to always use chdir. If ``-c'' is
not used at all, then ``-c3'' is assumed. Use ``-c0'' to prevent fas‐
trm from ever using chdir(2).
There are also ``-a'' and ``-r'' options, which do nothing at all,
except allow you to say ``fastrm -usa'' ``fastrm -ussr'' or ``fastrm
-user''. These happen to often be convenient sets of options to use.
Fastrm exits with a status of zero if there were no problems, or one if
something went wrong. Attempting to remove a file that does not exist
is not considered a problem. If the program exits with a non-zero sta‐
tus, it is probably a good idea to feed the list of files into an
``xargs rm'' pipeline.
This is revision 1.2, dated 1993/01/29.