Bug 83068

Summary:	dired glitch with filenames of form YYYY-MM-DD <space> foo.bar
Product:	[Retired] Red Hat Linux	Reporter:	Ed Price <edp>
Component:	emacs	Assignee:	Jens Petersen <petersen>
Status:	CLOSED UPSTREAM	QA Contact:	Brock Organ <borgan>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	8.0
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2003-01-31 03:22:09 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Ed Price 2003-01-29 22:32:11 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
dired doesnt navigate properly and cant open files with names of the form
YYYY-MM-DD <space> foo.bar, for example "2001-01-01 whatever.txt".
it displays the file name fine, but when moving forward and backward through the
directory listing, it positions the cursor incorrectly on the "whatever" (in the
example) rather than at the beginning of the file name as it should.  and when i
try to open the file (by typing "f" for find file) it says "File no longer
exists [...]".


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. touch "2001-01-01 test.dat"
2. emacs
3. "C-x C-f RET" (open the current directory in dired)
4. "n" until on that file.  (note incorrect cursor position.)
5. "f" to open the file.  (note failure to open file.)


Actual Results:  incorrect cursor position and failure to open file.


Expected Results:  normal cursor positioning and successful visit of the file.


Additional info:

emacs-version:

GNU Emacs 21.2.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2002-08-28
on astest

rpm -q emacs:

emacs-21.2-18


i also tried emacs v20 from redhat 7.2 and the bug did NOT occur there.

Comment 1 Jens Petersen 2003-01-30 06:09:54 UTC

Reproduced.  [FWIW xemacs dired works fine with filenames containing spaces.]

Of course it only occurs because of the iso date in filename...
Is there some particular application generating filenames of this form?

Comment 2 Jens Petersen 2003-01-30 07:50:09 UTC

`dired-move-to-filename-regexp' (dired.el) in cvs still has this
problem according to my testing, at least in 21.2.

Comment 3 Ed Price 2003-01-30 22:30:12 UTC

to answer the question about whether some app
was creating files with names of this form: no.
it was a user-chosen file name.

does emacs/dired have a test suite?  if so i'd
be happy to contribute a test case.  otherwise,
i'm not much of a regexp hacker, sorry :/
(i did look at dired.el...  all i can say is
it looks like it desperately *needs* a test
suite!)

Comment 4 Jens Petersen 2003-01-31 03:22:09 UTC

Btw a workaround is to remove "iso" from the final regexp
(assuming you're not using iso dates in dired that is),
or change your filenames not to have a space or something. ;-)

This whole problem is fixed in emacs cvs (using the --dired option of GNU ls)
and should appear in 21,4 I think, which is still a while off I'm afraid.

See all http://mail.gnu.org/archive/html/emacs-devel/2003-01/msg00828.html

Comment 5 Ed Price 2003-01-31 15:28:29 UTC

thx.  i did try removing "iso" part of the regexp and it did workaround this 
particular problem, though as you point out it's hardly a general solution.  
i'll look forward to handling of "--dired" output, that would be great (at 
least for local listings......).  thx again.