Bug 83068 - dired glitch with filenames of form YYYY-MM-DD <space> foo.bar
dired glitch with filenames of form YYYY-MM-DD <space> foo.bar
Status: CLOSED UPSTREAM
Product: Red Hat Linux
Classification: Retired
Component: emacs (Show other bugs)
8.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jens Petersen
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-01-29 17:32 EST by Ed Price
Modified: 2007-04-18 12:50 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-01-30 22:22:09 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ed Price 2003-01-29 17:32:11 EST
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 01:09:54 EST
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 02:50:09 EST
`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 17:30:12 EST
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-30 22:22:09 EST
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 10:28:29 EST
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.