NAME
OpenBSD::Vstat - virtual filesystem for "pkg_add(1)" simulations
SYNOPSIS
use OpenBSD::Vstat;
my $v = OpenBSD::Vstat->new($state);
$h = $v->add($filename, $size, $tag);
$v->remove($filename, $size);
$e = $v->exists($filename);
$v->tally;
DESCRIPTION
"OpenBSD::Vstat" provides methods to layout a virtual file system on top of the real one. This is generally used to simulate file system manipulations before doing them for real.
The constructor "new" expect a $state object, that is, an object with "$state->{not}" and "$state->errsay" defined.
Operations on the "Vstat" object can modify "$state->{problems}" and "$state->{overflow}".
The method "add" (respectively "remove") can be used to add a filename to the file system (resp. remove a filename from the file system). The method "exists" looks for a given filename: first it checks if it has been added or removed in the virtual filesystem. Failing that, it looks into the real file system using "-e".
Both "add" and "remove" also know about Unix filesystem semantics, namely mount(8) points and disk usage. They return a small object corresponding to the filename's file system with the following methods
- ro
- defined if the filesystem is read-only. Usually hard to add files there.
- nodev
- defined if the filesystem forbids devices.
- noexec
- defined if the filesystem forbids execution.
- nosuid
- defined if the filesystem forbids SUID files.
- avail
- returns the number of bytes still available on the filesystem.
"exists" returns a true value if the filename exists. If it is a virtual name added through "add", it returns the $tag specified as an optional argument. Otherwise, it returns 1.
"tally" displays a summary of filesystem manipulations after a series of additions and removals.
Due to the way packages get updated, size modifications through "remove" are delayed until the next call to "synchronize": old files must be removed before adding the new files in order to properly account for collisions, but the old files occupy disk space while the new package gets extracted.
Modifications to the virtual file system are stored until a call to "synchronize", which assumes the real file system will get those changes (and thus we can forget them), or "drop_changes", which assumes the changes won't get through, thus providing transactional semantics.
In case of file system overflow, "remove_first" can be used to indicate file removal happens before the creation of new files.
Typical use is as follows: do lot of changes to the Vstat object check for overflow. if so, drop_changes. redo the changes, with remove_first used instead of remove.
In case "$state->{not}" is true, the real file system will never store changes, and thus the "Vstat" object is layered to allow full transactional back-out.
BUGS AND LIMITATIONS
"OpenBSD::Vstat" now handles chroot(8) situations gracefully, but it doesn't know about symbolic links to directories and will report bogus results in complicated cases.
"OpenBSD::Vstat" needs an interface to deal with removed directories that get replaced with files. Currently, it will report a conflict.