Mail Archives: djgpp-workers/2003/08/03/06:58:24
Hello.
Andrew Cottrell wrote:
>
> FYI. WIP debugging update below.
>
> I have traced the problem so far to the rename() in move.c which is in
> LIBC!!!! The problem line is:-
>
> if (rename (src_path, dst_path)== 0)
> if (x->verbose && S_ISDIR (src_type))
> printf ("%s -> %s\n", quote_n (0, src_path), quote_n (1,
> dst_path));
[snip]
Thanks for the work!
fileutils 4.1 from Simtel.NET (built with 2.03): Has bug.
fileutils 4.1 from 2.04 testing page: Has bug.
coreutils 5.0 built by Andrew: Doesn't have bug.
I agree with Andrew: it's a library bug. Here's why:
Using something similar to Charles's test case, is_parent in
src/libc/ansi/stdio/rename.c seems to be called with one argument with an LFN
and one argument with a SFN. So the check to see whether the source is the
parent of the destination fails.
For some reason _truename returns an LFN when called on "junk" (real_old) and
an SFN when called on "junk/junk" (real_new) or "junk\\junk":
(gdb) p _truename(real_old, 0)
$15 = 0xad0a8 "C:\\thisisalongname\\junk"
(gdb) p _truename(real_new, 0)
$16 = 0xad0c8 "C:\\THISIS~1\\JUNK\\junk"
My current idea is that we could use _lfn_gen_short_fname to collapse
"thisisalongname" to thisis~1. I thought about patching _truename, but that
seems unsatisfactory. Any other ideas?
_truename is used in a couple of places where we compare filenames (is_parent,
_rename). Perhaps we should use some kind of _truename wrapper function there,
that does the LFN collapsing using _lfn_get_short_fname?
Items to do:
1a. is_parent in src/libc/ansi/stdio/rename.c.
1b. _truename wrapper for rename & _rename?
2. Add a warning to _truename docs.
3. "What's changed in 2.04" entry.
Thanks, bye, Rich =]
--
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]
- Raw text -