consistancy again s/file system/filesystem/g

This commit is contained in:
Tom Rhodes 2002-05-16 01:50:18 +00:00
parent 86fbd32683
commit 07d8c35ca3
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/www/; revision=13101
22 changed files with 87 additions and 87 deletions

View file

@ -1,6 +1,6 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" [
<!ENTITY base CDATA "..">
<!ENTITY date "$FreeBSD: www/en/projects/libh.sgml,v 1.5 2002/01/20 18:15:46 alex Exp $">
<!ENTITY date "$FreeBSD: www/en/projects/libh.sgml,v 1.6 2002/03/16 08:11:33 murray Exp $">
<!ENTITY title 'FreeBSD libh Project'>
<!ENTITY email 'freebsd-libh'>
<!ENTITY % includes SYSTEM "../includes.sgml"> %includes;
@ -255,7 +255,7 @@ case when a package is coming directly from an FTP server or some
other data source which offers only serial access to the bits.
pkg_add "solves" this problem by first finding sufficient temporary
space on one of the available file systems and then unpacking the
space on one of the available filesystems and then unpacking the
tarball to be extracted into a scratch directory. After the tarball
is extracted, pkg_add then reads through the "packing list" (one of
the meta-data files) and follow its instructions to move only those
@ -425,7 +425,7 @@ dependencies and nothing more (which is desirable), there are still
going to be pieces which are non-extractable under the current scheme
because the available disk space is too small to contain both the
temporary copy and the final installed copy, which may not be on the
same file system can cannot be simply moved into place. Since we'd
same filesystem can cannot be simply moved into place. Since we'd
also like to retain the ability to extract a package directly over a
network connection and never have the temporary bits "hit the disk",
this means that we're almost certainly going to have to go to a