bug-fileutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Memory consumption with cp -l


From: Jim Meyering
Subject: Re: Memory consumption with cp -l
Date: Mon, 10 Mar 2003 19:31:41 +0100

Ole Tange <address@hidden> wrote:
> On Mon, 10 Mar 2003, Jim Meyering wrote:
>
>> Knowing the bit about hard links, the increased memory footprint is
>> understandable.
>
> If this will not change in the near future may I suggest you mention this
> in the man-page in connection with the -l option?
>
>> There's probably a way to save some space in cases like yours.
>
> Correct me if I am wrong. But it seems to me that -l should never have to
> remember anything. -l can be emulated with a series of mkdir followed by a
> long serie of ln. None of the individual commands need any memory about
> what happened before.

Right, it's tempting to an exclusion for `cp --link', but that code
is still required to detect and properly diagnose pathological cases
like `cp --link dir dir/x/y/z'.  Yes, I'm the first to argue that support
for pathological cases shouldn't impact the common cases (at least not
too much), so someday I'll fix this.  I've added a note to the TODO file.
Here it is:

  copy.c: Address the FIXME-maybe comment in copy_internal.
  And once that's done, add an exclusion so that `cp --link'
  no longer incurs the overhead of saving src. dev/ino and dest. filename
  in the hash table.

And here's the comment in question:

     Also record directory dev/ino when using --recursive.  We'll use that
     info to detect this problem: cp -R dir dir.  FIXME-maybe: ideally,
     directory info would be recorded in a separate hash table, since
     such entries are useful only while a single command line hierarchy
     is being copied -- so that separate table could be cleared between
     command line args.  Using the same hash table to preserve hard
     links means that it may not be cleared.  */




reply via email to

[Prev in Thread] Current Thread [Next in Thread]