To get its configuration, zlibc first looks into the file described by the
environment variable LD_ZLIB_CONFFILE (if any), then in `~/.zlibrc' and
finally in `/usr/local/etc/zlibc.conf' (`/etc/zlibc.conf' on Linux Actually
Actually the location of the system-wide include file depends on the settings
of sysconfdir and prefix during ./configure (see section Compile-time
configuration). ). If the desired information is found in neither of these
files, the compiled-in defaults are used. It is possible to supply only part
of the needed information in the configuration files. In that case, the
missing information is retrieved from the compiled-in defaults. This allows
you to have really small runtime configuration files, which only list the
differences between the desired configuration and the compiled-in
If an error occurs while parsing one of the configuration files, the offending
file is skipped, and the search continues with the next file. However, no
error message is printed unless the environmental variable LD_ZLIB_VERBOSE is
turned on (i.e. set to 1 or to on ).
If two files contain contradictory information, the information in the file
which is scanned first is retained (usually `~/.zlibrc'). If any flags have
been set or unset using environmental variables, these settings override the
flags specified in the configuration files.
The configuration files are read by each process. For each process, they are
read at most once, at the time when zlibc is first used (attempt to access a
compressed file). Afterwards they are cached in the process's virtual memory.
Thus, changing zlibc configuration files doesn't generally have any effect on
already running processes.
The zlibrc files consist of two sections: A commands
line flags') and a class definition
section (`Class section').
The commands section describes how zlibc should behave depending on the
executable that it was called from. Several commands are grouped together into
The class definition section describes how zlibc should behave depending on the
class of the command and the datafile opened.
The configuration file may contain comments in both sections: a comment starts
with a hash (#) and stops at the end of the line.
Dashes (-) and underbars (_) may be used indifferently in all keywords.
The format for a line in the "commands" section is as follows:
commands " cmd1
" [ ... "cmdn
" ] use
In this line, the cmd1
are the basenames of the programs
(commands) for which this line should apply. The basename is the name without
the path, i.e. ls instead of /usr/bin/ls. The command names should be enclosed
in quotes. You may also use the keyword default (without quotes) to match all
describe those aspects of zlibc's behaviour that are
independant from the datafile which is being accessed. These flags come in
pairs. The flags need not to be listed on a single commands line, they may
occur in several places, even in several different configuration files (for
instance one in /etc/zlibc.conf and another one in ~/.zlibrc.
If two contradictory flags are found in the configuration files, the one which
is seen first is taken.
If on the other hand a certain flag is not found at all in the configuration
files, the compiled-in default for this flag is used. This is usually the
second flag of each pair, described below (see section Commands line flags).
These flags can all be overridden by environmental variables. When the
corresponding environmental variable is set to 1 or to on, the first flag is
used, when it is set to 0 or to off. If the environmental variables is set to
neither of these 4 values, it is ignored).
names the commands class that these commands belong to. If, for
a given command, two commands lines give different classes, the one which is
seen first is taken. No union of classes is made, the classes are always
treated as a whole. Thus, if you want to make a change to a command class, you
need to describe it in its entirety.
The following example says that the tar, cpio, pax, cp and mv show compressed
files in a directory listing (readdir_compr flag), and are of class
generic_safe. commands "tar" "cpio" "pax"
"cp" "mv" use readdir_compr "generic_safe"
The class generic_safe would then need to be described further in the class
This section describes the flags which can be used on a commands line. All these
flags come in pairs.
The table below describes each of these pairs. The first word in the header of
each item is the non-default flag, the second word is the default flag, and
the third word is the environmental variable by which you can override the
settings from the configuration files. If this environmental variable is
turned on (set to 1), the non-default (first) flag is taken, if it is turned
off (set to 0), the default (second) flag is taken.
The disable flag disables zlibc for the programs on this commands line. This is
useful for compression and uncompression utilities. Without this flag, gunzip
would not work anymore, because it would think that the uncompressed file
exists already, and it would refuse to overwrite this file.
The disable_child flag disables zlibc for the programs started by programs on
this commands line. This is implemented by removeing all occurrences of
uncompress.so from the LD_PRELOAD environment variable. This function is
useful for programs such as xemacs, in order to make sure that all launched
subprograms return results consistent with emacs itself (directory listings,
The readdir function shows the uncompressed files (i.e. with their trailing .gz
extension) when the readdir_compr flag is set, and the compressed files
When verbose is set, zlibc prints informational messages.
If the unlink flag is set, and if the user program tries to unlink a virtual
(uncompressed) file, the package translates this call into unlinking the real
file. If the no_unlink flag is set, requests to unlink virtual (uncompressed)
files are silently ignored.
A command classThese These command classes are unrelated to the classes in
object oriented programming.
definition describes those aspects of zlibc's behavior that depend on the name
of the datafile which is being accessed. Command classes are identified by a
name which is matched against the class
parameter from the commands.
The class name should be enclosed between quotes both in the commands line and
in the class definition.
The class section contains descriptions of different command classes (i.e
descriptions how datafiles should be uncompressed). Each class definition
begins with a line of the following format:
class " id
The class id
is the same string as the one used in the commands line. The
remaining lines of a class definition are as follows: [ [ criterion
" ]] mode
The following example shows the definition of the class used for X-servers.
# X uses tmp files in its own directories. class "X" subdir
"/usr/X11R6" usetmpfile subdir "/usr/X386" usetmpfile
subdir "/usr/lib/X11" usetmpfile showpipe
This says that all compressed files who are in a subdirectory below
`/usr/X11R6', `/usr/X386' or `/usr/lib/X11' are decompressed using temporary
files (usetmpfile), and that files from other directories are decompressed
using pipes (showpipe)
The following examples illustrates a command class, named nopipe, which always
uses temporary files for decompression # generic class which uses temp files
for all files. class "nopipe" usetmpfile
describes what parts of the filename should match:
The entire filename of the target data file must match name
The basename (filename without directory) of the target data file must match
The data file must live in the directory name
. If the user program opens
the file with an absolute pathname, that filename is used as is. If on the
other hand the user program uses a relative pathname, zlibc uses the most
direct path to the file (i.e. without symlinks).
The data file must live in the directory name
or in one of its
subdirectories. If the user program opens the file with an absolute pathname,
that filename is used as is. If on the other hand the user program uses a
relative pathname, zlibc uses the most direct path to the file (i.e. without
The data file's name must end in name
. This is useful for selecting files
according to their extension.
The data file must live on the same filesystem as name
. This criterion
can for example be used for example to disable zlibc on a doublespaced
filesystem (where zlibc would be redundant), or to switch off uncompressed
size reporting on an ftpfs filesystems uncompressed uncompressed size
reporting (see section Size would make ls painfully slow on an ftpfs
filesystem, as all files would have to be downloaded before their size could
All data files match. All class definitions must have a default line, and this
default line must be the last line of the definition. The default criterion
needs no 'name' parameter.
All data files match. Unlike default, this line needs not to be the last line of
the class definitions. Thus it is possible to specify several all lines for
different aspects of zlibc behaviour.
The lines of each class definition are scanned in sequence, and, for each
aspectSee See see section Mode , the first matching line is adopted. The class
may be defined in another initialisation file, if this file is scanned later.
parameter may be omitted if it can be deduced from the
. In that case, the following heuristics are used:
s beginning with a dot are considered as suffix.
s beginning with a slash, but not ending with a slash are considered
s beginning and ending with a slash are considered as subdirectory.
A missing name
is considered as default.
All the other name
s are considered as basename.
filesystem criteria, because these tend to be more predictable.
describes the behavior of zlibc in certain situations. These
are: What to do when a file is accessed in readonly mode. What to do when a
user program tries to append data to an existing file. What to do when a user
program tries to create a new file. What to do when a user program tries to
access an existing file and none of the preceding situations apply (see
section Write). Whether to show the size of the uncompressed file or the size
of the compressed file as a response to stat (see section Size).
The mode for each off these 5 situations has to be described separately. For
each of these 5 situations, the scan through the class description is done
until the reaction of zlibc for this situation is defined.
The reaction to a readonly request may be one of the following:
The uncompressed data file is sent to the user program using a pipe. This
consumes very few resources, and it allows the decompression to run in
paralell with the user process, but it has the disadvantage that the user
program cannot use lseek. To warn the user program of this, the data file is
shown as a named pipe (FIFO) when it is stat'ed.
This is the default setting. The data is uncompressed and put into a temporary
file. The user programs then reads its data from the temporary file. This has
the advantage that the user program may lseek, and the disadvantage that more
disk space is consumed, while the programming is accessing the file.
The data is sent through a pipe, but the file is shown as a regular file
("hidden") to the user program when it stats it. This might be
needed for programs which are picky about a file type, but who actually don't
The virtual (uncompressed) file is shown as non-existent to stat, and readdir
shows the physical (compressed) file. For certain programs, this is enough to
disable zlibc on a file per file basis. This is useful, for example, to make
emacs use its own compression support (crypt.el) instead of zlibc. Crypt.el is
able to compress files when writing them back, whereas zlibc isn't able to do
so. The leave-compressed doesn't work correctly with the directory and
subdirectory criteria. Use the filesystem criterion instead.
The virtual (uncompressed) file is shown to stat, but readdir shows the physical
(compressed) file. This is useful to tell zlibc that we prefer working on the
physical file, but without making access to the virtual file impossible. The
dir-leave-compressed doesn't work with the dir and subdir criteria. Use the
filesystem criterion instead.
The reaction to an append request may be one of the following:
When a user program tries to append data to a non-existant file, but the
corresponding compressed file exists, zlibc translates this request into
appending the compressed data to the compressed file.
This works with gzip, and might not work with other (un)compressors! This relies
on gzip's feature to consider a concatenation of compressed files as a
compression of concatenated files.
This is only reliable if you can guarantee that the file is not accessed by some
other program while the first one has it still open, or that it won't be
opened again (even by the same program) shortly after it has been closed.
Delays longer than a second should be ok. Don't enable append-compressed if
you expect the file to be written to by several programs at once.
Don't append to a compressed file (the user program will get a file not found
error). This is the default behavior.
The reaction to a create request may be one of the following:
When a user program tries to create a new file whose name matches the pattern,
zlibc translates this request into creating a compressed file. A file is
considered to be created, if the O_TRUNC flag is set, or if both O_CREAT and
O_EXCL are set. This only applies to files opened write-only.
This is only reliable if you can guarantee that the newly created file is not
accessed by some other program while the first one has it still open, or that
it won't be opened again (even by the same program) shortly after it has been
This should not be used if you expect the program to seek in this file.
Newly created files are created uncompressed. This is the default.
The reaction to other write requests may be one of the following:
When a user program tries to write to a non-existing file, and when a compressed
file with a corresponding name exists, this file is uncompressed in place
(i.e. having the same name, but without the .gz extension)
This is only safe when you can guarantee that the file is not opened by several
programs at once. However, once the call to the open function has returned,
other programs may open this file safely. If a second program tries to open
the file during the open call of the first, this second program gets a
When using this option, be careful when opening files belonging to another user,
or files living in a directory where you have no write access to. Using this
option in a directory without write access will result in a permission error.
Using this option in a directory where you do have write access will change
the ownership of the file to you, even if it belonged to another user
Compressed files are not uncompressed before writing to them, and zlibc returns
a "file not found" error. This is the default.
If several of these options apply for the same file, create-compressed has
priority over append-compressed which has priority over
When an application calls stat to fetch the attributes of a file (such as its
permissions, size, type, etc.), zlibc stats the corresponding compressed file
instead. After doing so, zlibc has to adjust some of the values returned by
stat, such as the type and the size. The type has to be adjusted for those
files that should be shown as pipes. The size has to be adjusted because user
programs are usually interested in the amount of data that they can actually
read from the file (i.e. the size of the uncompressed file) rather than the
size of the physical file (i.e. the size of the compressed file). However, in
order to find out the size of the uncompressed file, zlibc has to read some
data of the file, which may impact performance in situations where many files
are stat'ed. This is for instance the case for find, or for ls on an ftpfs
filesystem. The following two behaviors of the stat call may be specified:
Stat returns the size of the compressed file. This is less useful for the
application, but more efficient. If you mount any ftpfs filesystems, you may
switch on show-compressed-size just for that filesystem by using the
filesystem criterion (see section Criteria).
Stat returns the size of the uncompressed file. This is more useful for the
application, but less efficient. This is the default behavior.