GNU bug report logs - #10489
24.0.92; dired-do-copy may create infinite directory hierarchy

Previous Next

Package: emacs;

Reported by: michael_heerdegen <at> web.de

Date: Thu, 12 Jan 2012 19:36:01 UTC

Severity: important

Tags: patch

Merged with 11130

Found in version 24.0.92

Done: Chong Yidong <cyd <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 10489 <at> debbugs.gnu.org, michael.albinus <at> gmx.de, thierry.volpiatto <at> gmail.com
Subject: bug#10489: 24.0.92; dired-do-copy may create infinite directory hierarchy
Date: Sat, 14 Jan 2012 09:19:51 -0500
> > 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




This bug report was last modified 13 years and 58 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.