Configuration Files

Configuration Files

Does the project use any "hidden" files (filename begins with "."), system files, or temporary files? Are users going to need to be aware of them? Can they be left behind? Does their naming preclude simultaneous instances of a program?

Consider the differences between per-machine and cross-enterprise configuration mechanisms (files -vs- LDAP...) and how your project can work with both of them.

Consider what SMF, /etc/default/* or other resource/configuration files or databases will be used. In particular, consider any files used to store state between invocations. Will users expect to keep using them across minor--or even major--releases? For example, I expect my .mailrc file and /etc/aliases file to be used without error or incompatibility by a newer release.

Support a comment syntax (preferably from # to end-of-line) in customer-editable configuration files.

Private configuration files that save information behind a program or GUI, but which are not to be edited by hand, should (if a comment syntax is supported) have a comment saying not to edit it, which mentions what program(s) modify it.

Locking files

fcntl(2) has long been the POSIX compliant interface for locking; XPG4.2 adds lockf(3C) which is less complicated. Does your project clean up any locks/files after crashes?

File formats

Consider extending an existing file or format. If a project must define new file formats, is there an /etc/magic entry for any new file format? What will file(1) say?

Consider versioning the grammar and/or syntax used by the file so you can support upwardly compatible changes gracefully