Functions for dealing with tracking of files, and other installwatch related things.
Copyright (C) 2004 The Source Mage Team
Functions for dealing with tracking of files, and other installwatch related things.
Initialize libtrack, currently this is just the modified files list. This is used by cast to exclude files it's modified from the md5 list.
list of files
list of files
Reads a list of files from standard in, and returns a list of the files that exist.
Given a list of files it will notify installwatch of them. Useful for spells whose components are not dynamically linked to glibc. Uses simple hack of touching files while installwatch is running.
Some simple castfs sanity checking make a file, check to see if it exists, check to see if the contents of the file is what we made it
Starts Translation Stage Root
Stops Translation Stage Root
Prepare Stage Root
Destroy Stage Root
Sets up installwatch.
Stops using installwatch
Parses the installwatch log for files installed by a spell.
Creates the install log containing all files installed by the spell.
Creates the install log containing all staged files. It reuses the existing install log and just prepends $STAGE_DIRECTORY/TRANSL to every line
Makes a list of files with the md5sum
External api to note config files
Notes that a file was previously modified so that its md5 is deliberatly munged
Constructs the to-be cache name depending on the ARCHIVEBIN
Given a filename, will return the actual filename if a similar filename with a different extension exists. A more thorough version of guess_filename used for finding caches
Creates a bzip/gzip'ed tar file containing an archived backup of file specified on standard input into the target dir. Input files are relative to install root for regular files and state root for state files
this is to filter the install log from one form to another for install_root/track_root conversions
This filters an install log from a given format into another format
root: relative to / all paths are relative to / file existence tests should work, INSTALL_ROOT and STATE_ROOT are prepended to data and state files respectively log: relative to track_root etc, format used in the logs (see note on special behavior below) filterable: track_root/install_root/state_root stripped out files can have filters applied to them "Special" handling applies depending on whether STATE_ROOT is inside or outside INSTALL_ROOT. For converting into log format: If STATE_ROOT is within INSTALL_ROOT eg: STATE_ROOT=/opt/stuff INSTALL_ROOT=/opt/stuff or STATE_ROOT=/opt/stuff/state INSTALL_ROOT=/opt/stuff the portion of INSTALL_ROOT within STATE_ROOT is replaced with TRACK_ROOT if STATE_ROOT is outside of INSTALL_ROOT (eg /opt/stuff and /opt/state) then STATE_ROOT is left as is Converting from log to root format is the inverse, and of course going to filterable format just requires removing whatever the expected prefix is.
Split a log file into data that should be TRACK_ROOT'd versus STATE_ROOT'd.
Try to make a unique directory using $RANDOM, leverage the fact that two simultaneous mkdir's will have one succeed and the other fail. This is run from log_adjuster primarily which may be invoked several times in a pipe, when this happens, bash does a fork, but does not seem to reseed the random number generator, causing a high rate of collisions. This is not easily reproducable outside of sorcery at the time of writing, but inside it happens nearly everytime with bash 3.1. This may actually be a bash 3.1 bug. The collisions aren't bad necessarily, but they result in un-necesary delay. Setting RANDOM re-seeds the random number generator. Despite the fact that the subshell and invocation of date are slow the consequence for not doing them are worse. The nano-seconds are usually going to be different between forks so the liklihood of a collision is greatly reduced.