bug#10489: 24.0.92; dired-do-copy may create infinite directory hierarchy

[Stefan Monnier]

> > I don't mean "document what the code currently does" but "document
> > what the code should do".
> Same thing in this case.

I was just pointing out that basing the docstring on a sample
implementation is not the right way to do it.

> If we want to resolve the various cases of equivalent file names, we
> have no alternative but hitting the disk.

IIRC that's indeed the case if we want to consider equal the VFAT file
systems monste~1.  And that's exactly the kind of thing I want us to
decide by writing the docstring.  For POSIX the same question comes up
with symlinks.

>> >   "Return non-nil if NAME1 and NAME2 refer to the same file in the
>> > file system.  If either name is not absolute, then it is expanded
>> > relative to DIR (if given) or `default-directory' for the test."
>> That description is too vague: an implementation based on comparing
>> file-attributes would seem to fit, whereas it's clearly not the semantic
>> we want to provide.
> Sorry, I'm not following.  Why does a possibly different
> implementation make the doc string "too vague"?  IOW, the doc string
> _should_ be sufficiently "vague" to allow a change in the
> implementation without breaking the API or the semantics, right?

To me "the same name" is something quite different from "the same file".
I think file-name-equal-p should make it clear that it means "same name"
and not "same file" because we may want to use it without knowing if the
file exists and without opening a remote connection.

IIUC the original problem in dired-do-copy needs to test "same file"
rather than "same name", so it should not use file-name-equal-p but
file-equal-p (which would rely on file-attributes, presumably).


        Stefan