GNU bug report logs - #29189
25.3; Dired does not work with binary filenames

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: vianchielfaura <at> gmail.com, Kenichi Handa <handa <at> gnu.org>
Cc: schwab <at> suse.de, 29189 <at> debbugs.gnu.org
Subject: Re: bug#29189: 25.3; Dired does not work with binary filenames
Date: Sat, 11 Nov 2017 16:18:20 +0200

> Date: Sat, 11 Nov 2017 10:20:36 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: schwab <at> suse.de, 29189 <at> debbugs.gnu.org
> 
> > Without -b, the filename in Dired is two binary characters, \300 and
> > \265.  With -b, the filename in Dired is four characters, \265
> 
> Sorry, it seems I was confused.  You didn't originally say what file
> name you expected to see in Dired.  If the expected file name is \265,
> a single byte, but you see \300\265 instead, then the problem is not
> in deletion, the problem is in how Dired prepares file names for
> display.  I will look into that when I have time, if no one beats me
> to it.

The problem is in insert-directory.  It manually decodes each file
name which was output by 'ls', and that produces strangely
inconsistent results when the file name includes raw bytes: sometimes
we get the 2-byte sequence starting with \300, sometimes the original
byte survives unchanged, and sometimes I see the sequence \301\200
instead of a lone \300 in the file name.  I'm trying to understand
what's going on and find a solution to that.

CC'ing Handa-san in the hope that he could comment on this or provide
some suggestions.

Previous Next

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