Ole Tange <[EMAIL PROTECTED]> 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. */
_______________________________________________
Bug-fileutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-fileutils
