

Reading from the file: programs need to deal with hitting the end of the file before they got what they expected, so again the case of a zero-length file does not involve extra thinking for the programmer: he'll just hit end-of-file from the beginning.Searching for a string in a file: this is covered by the standard case of "if the file is shorter than the search term, it cannot contain the search term".Concatenating files: this is just a no-op with an empty file.


The git program (and others) tend to ignore empty directories, and if a project/administrator/user wants to have a record that the directory exists even though it has no useful content (yet), you may see an empty file named empty or empty.directory. This prevents overeager administrators from deleting empty directories after installation, and it also prevents bugs where a program or a user accidentally creates a file where the program would like to see a directory later. * Sometimes you see files where all the relevant text is in the file name, e.g. If the log file is empty, the number of errors is zero, which makes perfect sense. * To find out how many errors happened, you count the number of lines in the log files. * Error log files tend to be created empty, to be filled if and only if an error happens. Further complications arise if some other users created a file with that name in the mean time. Text editors that regularly make a backup would need special-case code to deal with the situation that the user might delete the last line, go to lunch, then come back and add another line.

