Date: Thu, 7 Mar 2002 20:00:10 -0800 (PST) From: Giorgos Keramidas <keramida@freebsd.org> To: freebsd-doc@freebsd.org Subject: Re: docs/35646: cp(1) page needs a "Bugs" section. Message-ID: <200203080400.g2840A394460@freefall.freebsd.org>
index | next in thread | raw e-mail
The following reply was made to PR docs/35646; it has been noted by GNATS.
From: Giorgos Keramidas <keramida@freebsd.org>
To: "Gary W. Swearingen" <swear@blarg.net>
Cc: bug-followup@freebsd.org
Subject: Re: docs/35646: cp(1) page needs a "Bugs" section.
Date: Fri, 8 Mar 2002 05:59:18 +0200 (EET)
Gary W. Swearingen wrote:
> Giorgos Keramidas <keramida@freebsd.org> writes:
>
> > Are you sure this should be documented in the manual page of cp(1) ?
> > Any program that copies data and doesn't take special care of 'holes' will
> > show similar behavior. Should we modify their manual pages too?
> >
> > [ See what dd(1) does instead of cp(1) below. ]
> [snip...]
> > Note that I'm not opposing the change. I'm only asking for ideas about all the
> > possible programs that will behave exactly like cp(1) and dd(1) do, when they
> > find files with 'holes'.
>
> You're clever to think of such things. If the OS could always hide the
> fact that it was compressing or uncompressing files like this, then it
> would never need mentioning outside the filesytem documenation. But it
> doesn't. A user of "cp" or "dd" should be able to predict, based on his
> reading of the man page or maybe some handbook, whether his use of the
> command will over-fill his filesystem. Currently, he must resort to
> trail and error, a method dear to many UNIX users, but not to many
> others. (Of course, many will not read about it until being bitten.)
A more general solution is needed. This is what I was trying to point out.
Many commands will do strange things with files that have holes. A few
that I could think off the top of my head were:
cat file1 > file2
cat < file1 > file2
cp file1 file2
awk scripts
sed scripts
perl filters
Practically, any command that does not have knowledge of the underlying
filesystem data-structures will copy the 'wrong' amount of data. AFAIK,
only dump(8) and restore(8) handle files with holes correctly; but these
commands work directly on the filesystem device.
I'll have to think about this a bit more. I'll get back to you soon.
Giorgos Keramidas FreeBSD Documentation Project
keramida@{freebsd.org,ceid.upatras.gr} http://www.FreeBSD.org/docproj/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203080400.g2840A394460>