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


Message #142 received at 10489 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 10489 <at> debbugs.gnu.org, michael.albinus <at> gmx.de, thierry.volpiatto <at> gmail.com
Subject: Re: bug#10489: 24.0.92;
	dired-do-copy may create infinite directory hierarchy
Date: Sat, 14 Jan 2012 10:59:03 +0200
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Fri, 13 Jan 2012 20:55:23 -0500
> Cc: 10489 <at> debbugs.gnu.org, Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
> 
> >> There's a crucial line missing between the above two.  It should clearly
> >> document what this function is expected to do.  E.g. it should make it
> >> clear if (and if so, to what extent) the function is allowed to refer to
> >> the actual file system(s) as opposed to only relying on the
> >> provided strings.
> > If the file name strings are not obviously equal, `file-truename' will
> 
> I don't mean "document what the code currently does" but "document
> what the code should do".

Same thing in this case.  If we want to resolve the various cases of
equivalent file names, we have no alternative but hitting the disk.

> >   "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?




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.