Mail Archives: djgpp-workers/1996/09/11/06:55:29
It seems that `strip' has problems with the notorious DOS "d:path"
drive-relative pathnames. "strip b:/prog.exe" works, but if I say
"strip b:prog.exe", I get this:
strip.exe: b:prog.exe: rename: Improper link (EXDEV)
This means that library function `rename' got two pathnames that are
on different drives, so it refuses to rename the file. I looked at the
code of `rename', and it only checks the first letter of the pathname and
that the second character is a colon, which seems OK:
/* Fail with EXDEV, if old and new aren't on the same device. */
if (old[1] == ':')
old_dev = toupper(old[0]) - 'A';
else
old_dev = getdisk();
if (new[1] == ':')
new_dev = toupper(new[0]) - 'A';
else
new_dev = getdisk();
if (old_dev != new_dev)
{
errno = EXDEV;
return -1;
}
So it seems that `rename' gets incorrect pathnames in this case.
Another problem is in the case when there are excessive slashes, like
this:
strip b://prog.exe
In that case, prog.exe is NOT stripped, but a temp file named b:/staaaaaa
is left which seems to be the stripped binary. (I've bumped on this
while testing GNU `install -s'; the excess slash is added by `install'
but they usually don't make any problems in DJGPP, because `put_path'
strips the redundant slashes, leaving only one.) So I'd guess that some
code in `strip' tries to parse the pathname, and fails in case of more
than one slash between any given pathname parts.
Curiously enough, the hackyish version of `strip', that Robert sent me
before the last snapshot hit the alpha site, doesn't have the last
problem (it does have the first one, though).
Advice of an old porter to DOS: if the code that assumes too much about
the shape of the pathnames (like that the first character must be a slash)
is scattered across the program, it might be easier to call `_fixpath' on
every argv[i] at the beginning of `main' and later only check the colon as
a directory separator (together with the slash).
- Raw text -