Mail Archives: djgpp-workers/2008/05/21/08:23:25
My port of Findutils is broken. As an user has reported it fails with ENOENT.
The reason why it fails under certain circunstances with that error is that
the directory contain symlinks. The reason for this failure is that the DIR
structure, after having been created by opendir(), initializes DIR->name with
something like this:
DIR->name="c:/foo/bar/*.*"
The above is only an example. Please note the trailing "*.*". This is the
source of the difficulties. I have not been envolved in the coding neither of
opendir() nor of readdir(), but as an average user I would expect that, as the
variable name suggests, the string should be the name of the directory to be
"opened" and not the directory name plus a search pattern. This means DIR->name
should looks like this:
DIR->name="c:/foo/bar"
or better:
DIR->name="c:/foo/bar/"
The trailing "/" to signal that "bar" is a (existing) directory. Of course I am
aware that "*.*" is a sane default for findfirst() that is issued by readdir().
Anyway, this is a design question and must be solved by someone else.
The offending code is in readdir() and is only trigger if the file is a symlink
of 510 bytes of length:
strcat(strcat(strcpy(fname, dir->name), "/"), dir->de.d_name);
As can be seen, inconditionaly, the string dir->name, that *always* has a "*.*"
appended if created by opendir(), gets appended a slash and the file name of
the symlink. E.G.: c:/foo/bar/*.*/link.txt. The wrong formed string fname is
then passed as argument to _open() and it fails with ENOENT. The easiest way
to solve the issue to remove "*.*" from fname and let dir->name unaltered to avoid
to break something. I will not propose any patch until the way to solve the issue
has not been decided.
Regards,
Juan M. Guerrero
- Raw text -