Maintaining filesystems can be a real administration burden. Over time you might start getting multiple copies of the same file, soft links that point to files that no longer exist, temporary files that have been hanging around longer than they should, and binaries that have been installed and not had their debugging information stripped out. fslint can help you find these troublesome files so you can clean up your filesystem.
Packages for fslint are available in Ubuntu Hardy universe and in the Fedora 9 repositories. There are currently no packages for openSUSE. I built it from source using version 2.28 of fslint on a 32-bit Fedora 9 machine. fslint is written in Python and uses GTK+2 and libglade2, so you'll need these and the Python bindings for them installed first.
You can execute fslint directly from the expanded tarball as shown below or install it onto your system manually as shown in the lower half of the below commands. The fslint-gui command brings up a GTK+2 graphical user interface. Other commands include fslint and a collection of commands starting with the
find prefix (for example,
findup to find duplicates), which are all command-line tools.
$ tar xzf /home/ben/Download/fslint-2.28.tar.gz
$ cd ./fslint*
$ su -l
# mkdir -p $sharedir
# chmod o+rx $sharedir
# cp -av doc $sharedir
# chown root.root $sharedir
# chown -R root.root $sharedir
# chmod o=rx $sharedir
# chmod o=r $sharedir
# install -m 444 fslint.desktop $prefix/applications
# install -pm 644 fslint.glade fslint_icon.png $sharedir
# ln -s $sharedir/fslint_icon.png $prefix/share/pixmaps/fslint.png
# install -m 444 man/fslint* $prefix/man/man1
# make -C po install
# install -m 755 fslint-gui $prefix/bin
# cp -av fslint $sharedir
# chmod -R 555 $sharedir/fslint
# cd $prefix/bin
# perl -pi -e 's|^liblocation=.*$|liblocation="/usr/local/share/fslint" |' fslint-gui
# perl -pi -e 's|^locale_base=.*$|locale_base=None |' fslint-gui
The first block of installation commands create a new directory in /usr/local/share/fslint and install the documentation files. The desktop, glade, icon, and manual pages are then installed, and make is used to install the localization files. The final two perl commands change two hard-coded paths in the fslint-gui Python code so that the glade file and other commands are sought in the correct paths. By default fslint-gui looks for the glade file in the same directory that it is executed from. This default allows you to execute fslint-gui directly in the expanded tarball, but you normally will not want to have the glade file in the same directory as the command itself.
The main window of fslint is shown below. The top part of the window lets you restrict what paths are searched and specify whether fslint will recurse into those directories. The Advanced search parameters tab lets you set paths to exclude as well as any extra parameters to pass directly to the invocation of the
find command. By default /tmp, .svn, CVS, .git, /dev, /sys, and /proc are included in the list of paths to be ignored.
The body of the window contains a number of tabs vertically ordered, each of which defines a particular lint test that you can execute. You have to remember to click on the Find button to rerun the search when you change lint tabs. This can be a trap if you have already executed Find while viewing a particular lint tab, then change lint tabs and expect that the results of the previous search has had any effect on the current tab.
The Duplicates tab lets you find if you have multiple copies of any files. Duplicate file detection first checks that two files have the same size, then that the files are not hardlinks, then computes the MD5 for both files to see if they are identical. When one or more duplicates of the same file are found, for each group of identical files, the utility displays a header line telling you how many duplicates exist and how many bytes are being wasted by storing the multiple copies. In the screenshot above you can see fslint showing duplicate results for a small collection of test files that I created. When you select a duplicate, the context menu lets you open, copy, or rename the file. fslint opens files with xdg-open, so you should see a familiar application open up for most common file types.
If you have the Installed packages tab shown and click on Find, fslint will show you all the packages you have installed on your machine. There is no context menu for the packages shown in the Installed packages list. If you are running fslint as root, you can click on the delete button to remove the selected packages.
The Bad names tab allows you to find files where the file name has an invalid UTF-8 encoding. The Name clashes tab lets you find all the aliases for a file or files -- files that have the same name but are located in different directories. The aliases of a file will include all the soft or hard links to the file. Finding files that have the same name but are in different directories can be handy if you are planning to copy files to a single directory or onto a filesystem that is not case-sensitive. Unfortunately the
-c option from the command-line
findsn utility, which performs the Name clash search, is not exposed through the GUI, because with the
-c option you can restrict the search to only showing files that are in the same directory and that have the same file name which differs only in the case of the name. Such files will cause issues when you copy them to case-insensitive filesystems. Anyone who has copied a directory tree into a flat structure on a flash drive will appreciate the name clash detection in fslint.
The Temp files tab lets you find temporary files that have been left around. You can restrict the search to only core files, and also specify the number of days old that the temporary file must be for fslint to report it. Normally, fslint checks the file name to detect if something is a temporary file -- such as files ending in ~, .swp, .v, or .bak or those starting with the # character. Although the core file test also matches on filenames first, checking whether the word
core is contained anywhere in the filename, there is a subsequent test to try to make sure the file is actually a core debug file.
The Bad symlinks tab lets you find dangling links (symlinks to files where the file being linked to has been deleted); suspect links, which are absolute links to paths within or below the directory containing the link; redundant links (containing "/./" or "///," for example); or simply find all absolute or relative links.
The Bad IDs tab lets you find files or directories that have a user or group ID that is not known to your system. Such files are might exist on NFS shares or where a tarball has been expanded and you do not have the same user names and group information on your machine as the person who created the tarball. However, I could not get the Bad IDs lint test to run in the GUI -- I always got an exceptions.NameError.
The Empty directories tab sums up its own functionality. The Redundant whitespace search lets you find files that are not properly indented or which contain white space at the end of lines.
The Non stripped binaries tab lets you search the paths you have nominated or the directories in your $PATH looking for executable files that have not had their debugging information stripped out. While you might like to have binaries which include debugging information if you are developing an application, you can save on RAM and obtain faster startup times if you strip the debugging information from your binaries.
fslint also provides a command-line utility that corresponds with each of the lint tabs.
Finding duplicate files and those with bad user and group IDs can help you help clean out the lint from your filesystem. The bad link detection ranges from the generally useful dangling link detection through to the more perfectionist case of finding links that include redundant portions in their definition. It would be a great addition if fslint could also automatically remove the redundancy from these links and recreate them in their most efficient manner.