GNU bug report logs - #1374
23.0.60; directory-files unexpectedly non-nil

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 1374 in the body.
You can then email your comments to 1374 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Markus Triska <markus.triska <at> gmx.at>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.0.60; directory-files unexpectedly non-nil
Date: Wed, 19 Nov 2008 05:01:09 +0100 (CET)

Let ~/tmp be initially empty, and create these 7 files in it via:

  for i in 0085-ottosson.ps.gz 0091-lindgren.ps.gz    \
           0104-pettersson-carlsson.ps.gz 0108-carlsson.ps.gz   \
           0118-lindgren.ps.gz 1076.pdf apl_slides.pdf; do touch $i; done

As expected,

   (directory-files "~/tmp" nil "nonexistent")

then yields "nil". However, after I evaluate (in emacs -Q) the forms:

   (defun my-log (start end old)
     (write-region (point-min) (point-min) "/tmp/my-log-file.tmp" t 'silent))

   (add-hook 'after-change-functions 'my-log)

the new result of

   (directory-files "~/tmp" nil "nonexistent")

is unexpectedly:

   ("apl_slides.pdf")

using OSX. In Ubuntu Intrepid, the new result is, again unexpectedly:

   ("1076.pdf")

In GNU Emacs 23.0.60.2 (i386-apple-darwin8.11.1, GTK+ Version 2.12.9)
 of 2008-11-05 on mt-computer.local
Windowing system distributor `The XFree86 Project, Inc', version 11.0.40400000
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_GB.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Message #10 received at 1374-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Markus Triska <markus.triska <at> gmx.at>
Cc: 1374-done <at> debbugs.gnu.org
Subject: Re: 23.0.60; directory-files unexpectedly non-nil
Date: Sat, 06 Dec 2008 20:02:24 -0500

This bug arose because the after-change-functions were triggered in the
code conversion work buffer, whereas directory-files assumed that
decoding a file name does not run arbitrary elisp code (otherwise, a
compiled regexp gets corrupted).  I've changed it so that
inhibit-modification-hooks is disabled in the code conversion buffer.

Thanks for the bug report.

Message #11 received at 1374-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Markus Triska <markus.triska <at> gmx.at>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 1374-done <at> debbugs.gnu.org
Subject: Re: 23.0.60; directory-files unexpectedly non-nil
Date: Sun, 07 Dec 2008 09:49:29 +0100

Chong Yidong <cyd <at> stupidchicken.com> writes:

> compiled regexp gets corrupted).  I've changed it so that
> inhibit-modification-hooks is disabled in the code conversion buffer.

Thank you; an unfortunate consequence is that modifications of the code
conversion buffer can now no longer be traced by after-change-functions;
I'm trying to trace down a different problem (#1125), and would like to
log buffer modifications as completely as possible. Is there a better
fix for this problem, i.e., can the regexp be preserved differently?

Message #12 received at 1374-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Markus Triska <markus.triska <at> gmx.at>
Cc: 1374-done <at> debbugs.gnu.org
Subject: Re: 23.0.60; directory-files unexpectedly non-nil
Date: Sun, 07 Dec 2008 09:11:36 -0500

Markus Triska <markus.triska <at> gmx.at> writes:

> Chong Yidong <cyd <at> stupidchicken.com> writes:
>
>> compiled regexp gets corrupted).  I've changed it so that
>> inhibit-modification-hooks is disabled in the code conversion buffer.
>
> Thank you; an unfortunate consequence is that modifications of the code
> conversion buffer can now no longer be traced by after-change-functions;
> I'm trying to trace down a different problem (#1125), and would like to
> log buffer modifications as completely as possible. Is there a better
> fix for this problem, i.e., can the regexp be preserved differently?

In general, I think we don't want to let user code run during code
conversion, because there may be other situations like this.

For the purposes of your bug tracking, try reverting the change I made,
and changing directory_files_internal so that it recompiles the regexp
after each call to DECODE_FILE:

*** trunk/src/dired.c.~1.157.~	2008-11-10 14:07:49.000000000 -0500
--- trunk/src/dired.c	2008-12-07 09:07:19.000000000 -0500
***************
*** 153,176 ****
    GCPRO5 (match, directory, list, dirfilename, encoded_directory);
    dirfilename = Fdirectory_file_name (directory);
  
-   if (!NILP (match))
-     {
-       CHECK_STRING (match);
- 
-       /* MATCH might be a flawed regular expression.  Rather than
- 	 catching and signaling our own errors, we just call
- 	 compile_pattern to do the work for us.  */
-       /* Pass 1 for the MULTIBYTE arg
- 	 because we do make multibyte strings if the contents warrant.  */
- # ifdef WINDOWSNT
-       /* Windows users want case-insensitive wildcards.  */
-       bufp = compile_pattern (match, 0,
- 			      buffer_defaults.case_canon_table, 0, 1);
- # else	/* !WINDOWSNT */
-       bufp = compile_pattern (match, 0, Qnil, 0, 1);
- # endif	 /* !WINDOWSNT */
-     }
- 
    /* Note: ENCODE_FILE and DECODE_FILE can GC because they can run
       run_pre_post_conversion_on_str which calls Lisp directly and
       indirectly.  */
--- 153,158 ----
***************
*** 179,187 ****
    encoded_directory = (STRING_MULTIBYTE (directory)
  		       ? ENCODE_FILE (directory) : directory);
  
-   /* Now *bufp is the compiled form of MATCH; don't call anything
-      which might compile a new regexp until we're done with the loop!  */
- 
    BLOCK_INPUT;
    d = opendir (SDATA (dirfilename));
    UNBLOCK_INPUT;
--- 161,166 ----
***************
*** 242,247 ****
--- 221,237 ----
  	  immediate_quit = 1;
  	  QUIT;
  
+ 	  if (!NILP (match))
+ 	    {
+ 	      CHECK_STRING (match);
+ # ifdef WINDOWSNT
+ 	      bufp = compile_pattern (match, 0,
+ 				      buffer_defaults.case_canon_table, 0, 1);
+ # else	/* !WINDOWSNT */
+ 	      bufp = compile_pattern (match, 0, Qnil, 0, 1);
+ # endif	 /* !WINDOWSNT */
+ 	    }
+ 
  	  if (NILP (match)
  	      || (0 <= re_search (bufp, SDATA (name), len, 0, len, 0)))
  	    wanted = 1;

Previous Next

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