Re: weird directory entry on ZFS volume (Re: else or Debian (Re: ZFS performance (was: Re: deduplicating file systems: VDO with Debian?)))
On Thu, Nov 10, 2022 at 02:48:28PM +0100, hw wrote:
> On Thu, 2022-11-10 at 07:03 -0500, Greg Wooledge wrote:
> good idea:
>
> printf %s * | hexdump
> 0000000 77c2 6861 0074
> 0000005
Looks like there might be more than one file here.
> > If you misrepresented the situation, and there's actually more than one
> > file in this directory, then use something like this instead:
> >
> > shopt -s failglob
> > printf '%s\0' ? | hd
>
> shopt -s failglob
> printf '%s\0' ? | hexdump
> 0000000 00c2
> 0000002
OK, that's a good result.
> > Note that the ? is *not* quoted here, because we want it to match any
> > one-character filename, no matter what that character actually is. If
> > this doesn't work, try ?? or * as the glob, until you manage to find it.
>
> printf '%s\0' ?? | hexdump
> -bash: Keine Entsprechung: ??
>
> (meaning something like "no equivalent")
The English version is "No match".
> printf '%s\0' * | hexdump
> 0000000 00c2 6177 7468 0000
> 0000007
I dislike this output format, but it looks like there are two files
here. The first is 0xc2, and the second is 0x77 0x61 0x68 0x74 if
I'm reversing and splitting the silly output correctly. (This spells
"waht", if I got it right.)
> > If it turns out that '?' really is the filename, then it becomes a ZFS
> > issue with which I can't help.
>
> I would think it is. Is it?
The file in question appears to have a name which is the single byte 0xc2.
Since that's not a valid UTF-8 character, ls chooses something to display
instead. In your case, it chose a '?' character. I'm guessing this is on
an older release of Debian.
In my case, it does this:
unicorn:~$ mkdir /tmp/x && cd "$_"
unicorn:/tmp/x$ touch $'\xc2'
unicorn:/tmp/x$ ls -la
total 80
-rw-r--r-- 1 greg greg 0 Nov 10 09:21 ''$'\302'
drwxr-xr-x 2 greg greg 4096 Nov 10 09:21 ./
drwxrwxrwt 20 root root 73728 Nov 10 09:21 ../
In my version of ls, there's a --quoting-style= option that can help
control what you see. But that's a tangent you can explore later.
Since we know the actual name of the file (subdirectory) now, let's just
rename it to something sane.
mv $'\xc2' subdir
Then you can investigate it, remove it, or do whatever else you want.
Reply to: