OpenBSD::Vstat(3p) Perl Programmers Reference Guide OpenBSD::Vstat(3p) #

OpenBSD::Vstat(3p) Perl Programmers Reference Guide OpenBSD::Vstat(3p)

NNAAMMEE #

 OpenBSD::Vstat - virtual filesystem for "pkg_add(1)" simulations

SSYYNNOOPPSSIISS #

     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;

DDEESSCCRRIIPPTTIIOONN #

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

BBUUGGSS AANNDD LLIIMMIITTAATTIIOONNSS #

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

perl v5.36.3 2020-12-20 OpenBSD::Vstat(3p)