Filewatcher File Search File Search
Catalog
Content Search
» » » » » zlibc_0.9k-4.1_i386.deb » Content »
pkg://zlibc_0.9k-4.1_i386.deb:70220/usr/share/man/man5/  info  control  downloads

zlibc - An on-fly auto-uncompressing C library…  more info»

zlibc.conf.5.gz

zlibc.conf(5)                                          zlibc.conf(5)





       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 Actu‐
       ally  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 dif‐
       ferences between the desired configuration and the  compiled-
       in configuration.

       If  an  error  occurs  while parsing one of the configuration
       files, the offending file is skipped, and the search  contin‐
       ues  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 informa‐
       tion in the file which is scanned first is retained  (usually
       `~/.zlibrc'). If any flags have been set or unset using envi‐
       ronmental variables, these settings override the flags speci‐
       fied 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). After‐
       wards 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  section
       (`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 command classe.

       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 fol‐
       lows:

       commands "cmd1" [ ... "cmdn" ] use flags "class"

       In this line, the cmd1 ... cmdn are the basenames of the pro‐
       grams (commands) for which this line should apply.  The base‐
       name 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 commands.

       The  flags  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).

       The class names the commands class that these commands belong
       to.  If, for a given command, two commands lines give differ‐
       ent 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  fur‐
       ther in the class section.



       This  section describes the flags which can be used on a com‐
       mands 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 com‐
       mands 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  imple‐
       mented 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, etc)

       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 otherwise.

       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  uncom‐
       pressed).  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  com‐
       mands  line. The remaining lines of a class definition are as
       follows: [ [ criterion ] [ "name" ]] 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  decom‐
       pressed  using  temporary  files (usetmpfile), and that files
       from other directories are decompressed  using  pipes  (show‐
       pipe)

       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



       The criterion  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 name.

       The data file must live in the directory name.  If  the  user
       program  opens the file with an absolute pathname, that file‐
       name 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  sym‐
       links).

       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 be reported.

       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' parame‐
       ter.

       All data files match. Unlike default, this line needs not  to
       be  the last line of the class definitions. Thus it is possi‐
       ble 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.
       The  criterion  parameter may be omitted if it can be deduced
       from the name. In that case,  the  following  heuristics  are
       used:

       Names beginning with a dot are considered as suffix.

       Names beginning with a slash, but not ending with a slash are
       considered as filename.

       Names beginning and ending with a  slash  are  considered  as
       subdirectory.

       A missing name is considered as default.

       All the other names are considered as basename.

       filesystem  criteria,  because  these  tend  to  be more pre‐
       dictable.



       The mode describes the behavior of zlibc  in  certain  situa‐
       tions. These are: What to do when a file is accessed in read‐
       only 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 follow‐
       ing:

       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 need lseek.

       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 with‐
       out making access to the virtual file  impossible.  The  dir-
       leave-compressed  doesn't work with the dir and subdir crite‐
       ria. Use the filesystem criterion instead.



       The reaction to an append request may be one of  the  follow‐
       ing:

       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.

       WARNING-1:

       This works with gzip, and might not work with other  (un)com‐
       pressors!   This  relies on gzip's feature to consider a con‐
       catenation of compressed files as a compression  of  concate‐
       nated files.

       WARNING-2:

       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 cre‐
       ating 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.

       WARNING-1:

       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 closed.

       WARNING-2:

       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 fol‐
       lowing:

       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)

       WARNING-1:

       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  dur‐
       ing  the  open  call of the first, this second program gets a
       permission error.

       WARNING-2:

       When using this option, be careful when opening files belong‐
       ing 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 initially.

       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 pri‐
       ority over uncompress-before-write.



       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.



ZLIBC                          27jun99                 zlibc.conf(5)
Results 1 - 1 of 1
Help - FTP Sites List - Software Dir.
Search over 15 billion files
© 1997-2017 FileWatcher.com