find-maint: Design Issues
1
1 3 Design Issues
1 ***************
1
1 The findutils package is installed on many many systems, usually as a
1 fundamental component. The programs in the package are often used in
1 order to successfully boot or fix the system.
1
1 This fact means that for findutils we bear in mind considerations
1 that may not apply so much as for other packages. For example, the fact
1 that findutils is often a base component motivates us to
1 * Limit dependencies on libraries
1 * Avoid dependencies on other large packages (for example,
1 interpreters)
1 * Be conservative when making changes to the 'stable' release branch
1
1 All those considerations come before functionality. Functional
1 enhancements are still made to findutils, but these are almost
1 exclusively introduced in the 'development' release branch, to allow
1 extensive testing and proving.
1
1 Sometimes it is useful to have a priority list to provide guidance
1 when making design trade-offs. For findutils, that priority list is:
1
1 1. Correctness
1 2. Standards compliance
1 3. Security
1 4. Backward compatibility
1 5. Performance
1 6. Functionality
1
1 For example, we support the '-exec' action because POSIX compliance
1 requires this, even though there are security problems with it and we
1 would otherwise prefer people to use '-execdir'. There are also cases
1 where some performance is sacrificed in the name of security. For
1 example, the sanity checks that 'find' performs while traversing a
1 directory tree may slow it down. We adopt functional changes, and
1 functional changes are allowed to make 'find' slower, but only if there
1 is no detectable impact on users who don't use the feature.
1
1 Backward-incompatible changes do get made in order to comply with
1 standards (for example the behaviour of '-perm -...' changed in order to
1 comply with POSIX). However, they don't get made in order to provide
1 better ease of use; for example the semantics of '-size -2G' are almost
1 always unexpected by users, but we retain the current behaviour because
1 of backward compatibility and for its similarity to the block-rounding
1 behaviour of '-size -30'. We might introduce a change which does not
1 have the unfortunate rounding behaviour, but we would choose another
1 syntax (for example '-size '<2G'') for this.
1
1 In a general sense, we try to do test-driven development of the
1 findutils code; that is, we try to implement test cases for new features
1 and bug fixes before modifying the code to make the test pass. Some
1 features of the code are tested well, but the test coverage for other
1 features is less good. If you are about to modify the code for a
1 predicate and aren't sure about the test coverage, use 'grep' on the
1 test directories and measure the coverage with 'lcov' or another test
1 coverage tool.
1
1 You should be able to use the 'coverage' Makefile target (it's
1 defined in 'maint.mk' to generate a test coverage report for findutils.
1 Due to limitations in 'lcov', this only works if your build directory is
1 the same asthe source directory (that is, you're not using a VPATH build
1 configuration).
1
1 Lastly, we try not to depend on having a "working system". The
1 findutils suite is used for diagnosis of problems, and this applies
1 especially to 'find'. We should ensure that 'find' still works on
1 relatively broken systems, for example systems with damaged
1 '/etc/passwd' or '/etc/fstab' files. Another interesting example is the
1 case where a system is a client of one or more unresponsive NFS servers.
1 On such a system, if you try to stat all mount points, your program will
1 hang indefinitely, waiting for the remote NFS server to respond.
1
1 Another interesting but unusual case is broken NFS servers and
1 corrupt filesystems; sometimes they return 'impossible' file modes.
1 It's important that find does not entirely fail when encountering such a
1 file.
1