On Thursday 24 August 2006 16:45, Julian Elischer wrote:
Eric Anderson wrote:
On 08/20/06 04:21, Mike Silbersack wrote:
On Wed, 26 Jul 2006, Eric Anderson wrote:
I'm tired of trying to use rsync or gcp (which doesn't like symlinks
often) to copy trees of files/directories using
At 9:05 AM -0400 8/25/06, John Baldwin wrote:
On 24 August 2006, Julian Elischer wrote in a cvs-commit log:
Add an option to allow copying of a hierarchy while
linking he regular files.
Very good for commiting this -- except that I'm not quite
sure that log-message is parseable! From
On 08/25/06 11:49, Garance A Drosehn wrote:
At 9:05 AM -0400 8/25/06, John Baldwin wrote:
On 24 August 2006, Julian Elischer wrote in a cvs-commit log:
Add an option to allow copying of a hierarchy while
linking he regular files.
Very good for commiting this -- except that I'm not
On 08/20/06 04:21, Mike Silbersack wrote:
On Wed, 26 Jul 2006, Eric Anderson wrote:
I'm tired of trying to use rsync or gcp (which doesn't like symlinks often)
to copy trees of files/directories using hard links, so I added the gcp-ish
options -a and -l.
...
Comments? Flames? Committers
Eric Anderson wrote:
On 08/20/06 04:21, Mike Silbersack wrote:
On Wed, 26 Jul 2006, Eric Anderson wrote:
I'm tired of trying to use rsync or gcp (which doesn't like symlinks
often) to copy trees of files/directories using hard links, so I
added the gcp-ish options -a and -l.
...
On Wed, 26 Jul 2006, Eric Anderson wrote:
I'm tired of trying to use rsync or gcp (which doesn't like symlinks often)
to copy trees of files/directories using hard links, so I added the gcp-ish
options -a and -l.
...
Comments? Flames? Committers willing to commit?
Eric
Having just read
Julian Elischer wrote:
Oliver Fromme wrote:
Bakul Shah wrote:
Peter Jeremy wrote:
As a general comment (not addressed to Tim): There _is_ a downside
to sparsifying files. If you take a sparse file and start filling
in the holes, the net result will be very badly
In message: [EMAIL PROTECTED]
John Baldwin [EMAIL PROTECTED] writes:
: On Monday 31 July 2006 14:53, Mike Meyer wrote:
: Which points up an obvious question: other than compatibility with
: Linux, is there any reason this functionaly shouldn't be added to the
: ln command instead?
:
Rick C. Petty wrote:
... I don't think cp or tar do [handle extended attributes] either.
Actually, the OS-independent code for extended
attributes has already been implemented in libarchive,
thanks to Jaako Heinonen, who also wrote the
Linux-specific portions for archive_extract
(restore to
Rick C. Petty wrote:
While we're at it, I think we should add the -S option to bsdtar. I'm
willing to do the work ...
I have pretty strong ideas about sparse file support
for bsdtar.
The cheap solution is to handle it purely on
extract: Detect blocks of zeros when restoring
files and seek
On Tue, 2006-Aug-01 23:35:03 -0700, Tim Kientzle wrote:
The cheap solution is to handle it purely on
extract: Detect blocks of zeros when restoring
files and seek over them.
The downside is that you wind up with a sparse file whether or not you
wanted one.
I simply dislike
the GNU tar
On Wed, 2 Aug 2006, Peter Jeremy wrote:
As a general comment (not addressed to Tim): There _is_ a downside to
sparsifying files. If you take a sparse file and start filling in the
holes, the net result will be very badly fragmented and hence have very
poor sequential I/O performance. If
As a general comment (not addressed to Tim): There _is_ a downside
to sparsifying files. If you take a sparse file and start filling
in the holes, the net result will be very badly fragmented and hence
have very poor sequential I/O performance. If you're never going to
update a file then
Peter Jeremy wrote:
As a general comment (not addressed to Tim): There _is_ a downside
to sparsifying files.
How people use (or misuse) such a feature is just
not my concern. I've not seen anyone
on this thread suggest that such sparsification
be done by default, and there are certainly rare
On Wed, Aug 02, 2006 at 05:33:40PM +1000, Peter Jeremy wrote:
On Tue, 2006-Aug-01 23:35:03 -0700, Tim Kientzle wrote:
The cheap solution is to handle it purely on
extract: Detect blocks of zeros when restoring
files and seek over them.
The downside is that you wind up with a sparse file
Bakul Shah wrote:
Peter Jeremy wrote:
As a general comment (not addressed to Tim): There _is_ a downside
to sparsifying files. If you take a sparse file and start filling
in the holes, the net result will be very badly fragmented and hence
have very poor sequential I/O performance.
Oliver Fromme wrote:
Bakul Shah wrote:
Peter Jeremy wrote:
As a general comment (not addressed to Tim): There _is_ a downside
to sparsifying files. If you take a sparse file and start filling
in the holes, the net result will be very badly fragmented and hence
have very poor
On Mon, 2006-Jul-31 22:42:49 +0200, Ivan Voras wrote:
I agree with this, and while you're in there, can you add -s to copy
sparse files (via the usual if the buffer is all nulls, seek beyond eof
instead of writing trick)?
Note that it isn's possible to accurately distinguish between a block
of
Peter Jeremy wrote:
Note that it isn's possible to accurately distinguish between a block
of NULs and a hole in the file through the filesystem. The only way
to accurately copy a sparse file is with dump/restore.
Hence the need for an explicit switch.
This is true in the desktop and server
On 07/26/06 21:51, Eric Anderson wrote:
I'm tired of trying to use rsync or gcp (which doesn't like symlinks
often) to copy trees of files/directories using hard links, so I added
the gcp-ish options -a and -l.
-a is 'archive' mode, which is just a quick form of -PpR.
-l is 'link' mode, where
On Tue, 01 Aug 2006, Ivan Voras wrote:
Peter Jeremy wrote:
Note that it isn's possible to accurately distinguish between a block
of NULs and a hole in the file through the filesystem. The only way
to accurately copy a sparse file is with dump/restore.
Hence the need for an explicit
At 12:07 PM +0200 8/1/06, Ivan Voras wrote:
Peter Jeremy wrote:
Note that it isn's possible to accurately distinguish
between a block of NULs and a hole in the file through
the filesystem. The only way to accurately copy a
sparse file is with dump/restore.
Hence the need for an explicit
On Tue, Aug 01, 2006 at 05:26:11PM +1000, Peter Jeremy wrote:
On Mon, 2006-Jul-31 22:42:49 +0200, Ivan Voras wrote:
I agree with this, and while you're in there, can you add -s to copy
sparse files (via the usual if the buffer is all nulls, seek beyond eof
instead of writing trick)?
Note
On Tue, Aug 01, 2006 at 01:06:55PM -0400, Garance A Drosehn wrote:
The point is not that you need an explicit switch, the
point is that you have to add a lot of code to 'cp' for
'cp' to do the job correctly.
Not really. See my example in a previous post. All you need to do is
perform an
On 08/01/06 12:11, Rick C. Petty wrote:
On Tue, Aug 01, 2006 at 05:26:11PM +1000, Peter Jeremy wrote:
On Mon, 2006-Jul-31 22:42:49 +0200, Ivan Voras wrote:
I agree with this, and while you're in there, can you add -s to copy
sparse files (via the usual if the buffer is all nulls, seek beyond
On Tue, Aug 01, 2006 at 12:27:54PM -0500, Eric Anderson wrote:
Wouldn't this be incorrect for files that are really full of zeros? It
would turn them in to sparse files when they shouldn't be, correct? Is
that what happens with other tools?
Why is this bad? I'm not suggesting that the
On 08/01/06 12:40, Rick C. Petty wrote:
On Tue, Aug 01, 2006 at 12:27:54PM -0500, Eric Anderson wrote:
Wouldn't this be incorrect for files that are really full of zeros? It
would turn them in to sparse files when they shouldn't be, correct? Is
that what happens with other tools?
Why is
On Tue, Aug 01, 2006 at 12:51:32PM -0500, Eric Anderson wrote:
On 08/01/06 12:40, Rick C. Petty wrote:
It could possibly be bad if you have a real file (say a 10GB file,
partially filled with zeros - a disk image created with dd for
instance), and you use cp with something like -spR to
In [EMAIL PROTECTED], Rick C. Petty [EMAIL PROTECTED] typed:
On Tue, Aug 01, 2006 at 05:26:11PM +1000, Peter Jeremy wrote:
On Mon, 2006-Jul-31 22:42:49 +0200, Ivan Voras wrote:
I agree with this, and while you're in there, can you add -s to copy
sparse files (via the usual if the buffer is
On Tue, Aug 01, 2006 at 02:26:28PM -0400, Mike Meyer wrote:
In [EMAIL PROTECTED], Rick C. Petty [EMAIL PROTECTED] typed:
Obviously, I didn't add the error checking/handling, but AFAIK this is
essentially what the -S option to gnu's tar does.
Yes, but gnu tar doesn't do this accurately,
Eric Anderson wrote:
On 08/01/06 12:40, Rick C. Petty wrote:
On Tue, Aug 01, 2006 at 12:27:54PM -0500, Eric Anderson wrote:
Wouldn't this be incorrect for files that are really full of zeros?
It would turn them in to sparse files when they shouldn't be,
correct? Is that what happens with
Eric Anderson wrote:
On 08/01/06 12:11, Rick C. Petty wrote:
On Tue, Aug 01, 2006 at 05:26:11PM +1000, Peter Jeremy wrote:
On Mon, 2006-Jul-31 22:42:49 +0200, Ivan Voras wrote:
I agree with this, and while you're in there, can you add -s to
copy sparse files (via the usual if the buffer
On Tue, 2006-Aug-01 12:51:32 -0500, Eric Anderson wrote:
string of zeros larger than the block size, or it needs to 'do the right
thing' and determine if it's sparse or not.
You can do this by comparing stat.st_size with stat.st_blocks - a
sparse file will have fewer blocks than its size
On Wed, Aug 02, 2006 at 05:04:53AM +1000, Peter Jeremy wrote:
On Tue, 2006-Aug-01 12:51:32 -0500, Eric Anderson wrote:
string of zeros larger than the block size, or it needs to 'do the right
thing' and determine if it's sparse or not.
You can do this by comparing stat.st_size with
On Wed, Aug 02, 2006 at 05:04:53AM +1000, Peter Jeremy wrote:
On Tue, 2006-Aug-01 12:51:32 -0500, Eric Anderson wrote:
string of zeros larger than the block size, or it needs to 'do the right
thing' and determine if it's sparse or not.
You can do this by comparing stat.st_size with
Eric Anderson wrote:
It could possibly be bad if you have a real file (say a 10GB file,
partially filled with zeros - a disk image created with dd for
instance), and you use cp with something like -spR to recursively copy
all files. Your destination disk image would then be a sparse file, so
Mike Meyer wrote:
I always think of cp as a tool for making *copies of files*, not for
creating an archive of a directory tree. We've got lots of tools that
do the latter. Do we really need another one?
But, but, but - I only asked for cp to be able to copy my sparse files
as sparse files,
Eric Anderson wrote:
It could possibly be bad if you have a real file (say a 10GB file,
partially filled with zeros - a disk image created with dd for
instance), and you use cp with something like -spR to recursively copy
all files. Your destination disk image would then be a sparse
At 12:19 PM -0500 8/1/06, Rick C. Petty wrote:
On Tue, Aug 01, 2006, Garance A Drosehn wrote:
The point is not that you need an explicit switch, the
point is that you have to add a lot of code to 'cp' for
'cp' to do the job correctly.
Not really. See my example in a previous post. All
On Tue, Aug 01, 2006 at 08:09:08PM -0400, Garance A Drosehn wrote:
I had understood this option as a request to copy all the
existing holes, which is not the same thing. I.e., I
thought we wanted `cp' to create the new file such that it
would take up exactly the same number of disk blocks,
At 7:17 PM -0500 8/1/06, Rick C. Petty wrote:
On Tue, Aug 01, 2006 at 08:09:08PM -0400, Garance A Drosehn wrote:
I had understood this option as a request to copy all the
existing holes, which is not the same thing. I.e., I
thought we wanted `cp' to create the new file such that it
would
On 07/27/06 12:44, Doug Barton wrote:
Oliver Fromme wrote:
Eric Anderson [EMAIL PROTECTED] wrote:
I'm tired of trying to use rsync or gcp (which doesn't like symlinks
often) to copy trees of files/directories using hard links, so I added
the gcp-ish options -a and -l.
-a is
In [EMAIL PROTECTED], Eric Anderson [EMAIL PROTECTED] typed:
The patch doesn't change any current behavior, nor should it be noticed
by anyone not looking for it. However, it is useful, and it does make
our cp work just like the GNU cp, which eases the migration path for
linux-FreeBSD
On 07/31/06 09:11, Mike Meyer wrote:
In [EMAIL PROTECTED], Eric Anderson [EMAIL PROTECTED] typed:
The patch doesn't change any current behavior, nor should it be noticed
by anyone not looking for it. However, it is useful, and it does make
our cp work just like the GNU cp, which eases the
In [EMAIL PROTECTED], Eric Anderson [EMAIL PROTECTED] typed:
On 07/31/06 09:11, Mike Meyer wrote:
In [EMAIL PROTECTED], Eric Anderson [EMAIL PROTECTED] typed:
The patch doesn't change any current behavior, nor should it be noticed
by anyone not looking for it. However, it is useful, and
On 7/31/06, Mike Meyer [EMAIL PROTECTED] wrote:
In [EMAIL PROTECTED], Eric Anderson [EMAIL PROTECTED]
typed:
On 07/31/06 09:11, Mike Meyer wrote:
In [EMAIL PROTECTED], Eric Anderson
[EMAIL PROTECTED] typed:
The patch doesn't change any current behavior, nor should it be
noticed
by
In [EMAIL PROTECTED], Juan Rodriguez [EMAIL PROTECTED] typed:
On 7/31/06, Mike Meyer [EMAIL PROTECTED] wrote:
My GNU version of cp has more than 18 options, the FreeBSD
version only has 9.
And this results in:
student% uname -a
Linux student.mired.org 2.6.12-9-386 #1 Mon Oct 10 13:14:36 BST
On 7/31/06, Mike Meyer [EMAIL PROTECTED] wrote:
In [EMAIL PROTECTED], Juan
Rodriguez [EMAIL PROTECTED] typed:
On 7/31/06, Mike Meyer [EMAIL PROTECTED]
wrote:
My GNU version of cp has more than 18 options, the FreeBSD
version only has 9.
And this results in:
student% uname -a
Linux
On Mon, 31 Jul 2006, Mike Meyer wrote:
snake% uname -a
FreeBSD snake.mired.org 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sun May 7 04:42:56
UTC 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP i386
snake% ls -l /bin/cp
-r-xr-xr-x 1 root wheel 15300 May 6 23:56 /bin/cp
flea# ls -l cp
On Mon, Jul 31, 2006 at 05:47:09PM +0200, Juan Rodriguez wrote:
My GNU version of cp has more than 18 options, the FreeBSD
version only has 9.
As I usually work with Linux machines, I'm used to cp -a and I have always
hated to have to look up in the FreeBSD's cp manual page for the right
On 07/31/06 12:28, Rick C. Petty wrote:
On Mon, Jul 31, 2006 at 05:47:09PM +0200, Juan Rodriguez wrote:
My GNU version of cp has more than 18 options, the FreeBSD
version only has 9.
As I usually work with Linux machines, I'm used to cp -a and I have always
hated to have to look up in the
the first one because of compatibility with the large base of Linux systems
out there,
I'll say it again: Being compatible with some other system is *not* a
reason to add something to FreeBSD. Sure, if we decide a feature is
useful, then there's a lot to be said for making it compatible with
On 07/31/06 10:23, Mike Meyer wrote:
In [EMAIL PROTECTED], Eric Anderson [EMAIL PROTECTED] typed:
On 07/31/06 09:11, Mike Meyer wrote:
In [EMAIL PROTECTED], Eric Anderson [EMAIL PROTECTED] typed:
The patch doesn't change any current behavior, nor should it be noticed
by anyone not looking for
On Mon, Jul 31, 2006 at 12:42:02PM -0500, Eric Anderson wrote:
On 07/31/06 12:28, Rick C. Petty wrote:
In both cases, why don't you just use:
/usr/compat/linux/bin/cp
Two reasons - it's not in the base system, so a port has to be installed
- and linux_base is FC3 now, so if you want to
On 07/31/06 13:44, Rick C. Petty wrote:
On Mon, Jul 31, 2006 at 12:42:02PM -0500, Eric Anderson wrote:
On 07/31/06 12:28, Rick C. Petty wrote:
In both cases, why don't you just use:
/usr/compat/linux/bin/cp
Two reasons - it's not in the base system, so a port has to be installed
- and
In [EMAIL PROTECTED], Eric Anderson [EMAIL PROTECTED] typed:
On 07/31/06 10:23, Mike Meyer wrote:
In [EMAIL PROTECTED], Eric Anderson [EMAIL PROTECTED] typed:
On 07/31/06 09:11, Mike Meyer wrote:
I suppose I'm just missing the reason *not* to commit such a simple and
n useful set of
Mike Meyer wrote:
I'm as neutral as I'd be about *any* other addition. I don't have a
specific reason to dislike it. But I don't have a specific reason to
like it, either. The last time I wanted a hardlinked copy of a
directory tree was long enough ago that most (if not all) of the
alternative
At 12:17 PM -0700 7/31/06, Julian Elischer wrote:
Ok Im going to pipe up here.
The feature is cheap, it is useful and it allows people
to adopt FreeBSD with less surprises. I will commit
this soon unless someone else does it first.
This is not the first time we have had a long thread
about
Mike Meyer wrote:
snake% uname -a
FreeBSD snake.mired.org 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sun May 7 04:42:56
UTC 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP i386
snake% ls -l /bin/cp
-r-xr-xr-x 1 root wheel 15300 May 6 23:56 /bin/cp
To badly paraphase [1] a quote: Here,
Eric Anderson wrote:
-a is 'archive' mode, which is just a quick form of -PpR.
-l is 'link' mode, where regular files get hard linked instead of copied.
I agree with this, and while you're in there, can you add -s to copy
sparse files (via the usual if the buffer is all nulls, seek beyond
Rick C. Petty wrote:
-l may be a useful option, but at what point is the line drawn between
bloating our base cp and having a gcp port (or using linux_base)??
It's like saying if you need this option, go to Linux - it just seems
wrong.
With all respect to series of small utilities way of
On Monday 31 July 2006 14:53, Mike Meyer wrote:
Which points up an obvious question: other than compatibility with
Linux, is there any reason this functionaly shouldn't be added to the
ln command instead?
Umm, because ln doesn't copy hierarchies? Using that argument we'd remove
support for
On Mon, Jul 31, 2006 at 11:01:24PM +0200, Ivan Voras wrote:
Rick C. Petty wrote:
-l may be a useful option, but at what point is the line drawn between
bloating our base cp and having a gcp port (or using linux_base)??
It's like saying if you need this option, go to Linux - it just seems
Rick C. Petty wrote:
think that more BSD admins are so used to typing cp -pR than cp -a. In
Ah, but therein lies one of the points - Percentage of BSD admins vs
other-unix-like-systems admins is slowly but steadily diminishing. In
my (I'll admit - not so expansive) experience BSD admins
Ivan Voras wrote this message on Tue, Aug 01, 2006 at 00:07 +0200:
older people who stick with what they know will work - vast majority of
younger admins I know either personally or on the 'net generally know
only Linux.
Using common options help bring people over, and also saves trouble
John-Mark Gurney wrote:
Helping people not be portable w/ other Unixes like Solaris is something
we should not do... Can anyone name another major Unix besides Linux that
has the -a option?
I won't continue this line of discussion more, but it's possible Linux
has more traction in these
Eric Anderson wrote:
So, you can mimic an entire tree with something like:
cp -al /from/ /to/
pax -rwl -pe /from /to
is almost what you want. (It requires
that /to exist first, though.)
If you want to match the 'cp' semantics when /to does
not exist, you can use pax's rewrite option:
pax
Eric Anderson [EMAIL PROTECTED] wrote:
I'm tired of trying to use rsync or gcp (which doesn't like symlinks
often) to copy trees of files/directories using hard links, so I added
the gcp-ish options -a and -l.
-a is 'archive' mode, which is just a quick form of -PpR.
-P is the
Oliver Fromme wrote:
Eric Anderson [EMAIL PROTECTED] wrote:
I'm tired of trying to use rsync or gcp (which doesn't like symlinks
often) to copy trees of files/directories using hard links, so I added
the gcp-ish options -a and -l.
-a is 'archive' mode, which is just a quick form
On Thursday 27 July 2006 13:44, Doug Barton wrote:
Oliver Fromme wrote:
Eric Anderson [EMAIL PROTECTED] wrote:
I'm tired of trying to use rsync or gcp (which doesn't like symlinks
often) to copy trees of files/directories using hard links, so I added
the gcp-ish options -a and -l.
I'm tired of trying to use rsync or gcp (which doesn't like symlinks
often) to copy trees of files/directories using hard links, so I added
the gcp-ish options -a and -l.
-a is 'archive' mode, which is just a quick form of -PpR.
-l is 'link' mode, where regular files get hard linked instead of
On 07/26/06 21:51, Eric Anderson wrote:
The patch attached had some junk in it. The patch on the website
doesn't have that. :) Oops..
Eric
[..snip..]
--- etc/mtree/BSD.include.dist 16 Nov 2005 10:50:10 - 1.100.2.2
+++ etc/mtree/BSD.include.dist 26 Jul 2006 03:42:10 -
@@
Eric Anderson wrote:
I'm tired of trying to use rsync or gcp (which doesn't like symlinks
often) to copy trees of files/directories using hard links, so I added
the gcp-ish options -a and -l.
-a is 'archive' mode, which is just a quick form of -PpR.
-l is 'link' mode, where regular files get
On Wed, Jul 26, 2006 at 08:51:13PM -0700 I heard the voice of
Julian Elischer, and lo! it spake thus:
I've always used:
find . -depth |cpio -pdlmv $dest
While we're in workarounds, I fake with:
% cat ~/bin/tarcp.sh
#!/bin/sh
cmd1=tar -cf - -C $1 .
cmd2=tar -xvpf - -C $2
echo $cmd1 | $cmd2
74 matches
Mail list logo
