Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 83068 - dired glitch with filenames of form YYYY-MM-DD <space> foo.bar
Summary: dired glitch with filenames of form YYYY-MM-DD <space> foo.bar
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: emacs
Version: 8.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jens Petersen
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-01-29 22:32 UTC by Ed Price
Modified: 2007-04-18 16:50 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-01-31 03:22:09 UTC


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.