From: Robert White <rwhite@pobox.com>
To: russell@coker.com.au, Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: strange 3.16.3 problem
Date: Sat, 18 Oct 2014 06:33:10 -0700 [thread overview]
Message-ID: <54426C16.5030206@pobox.com> (raw)
In-Reply-To: <201410181454.19375.russell@coker.com.au>
On 10/17/2014 08:54 PM, Russell Coker wrote:
> # find . -name "*546"
> ./1412233213.M638209P10546
> # ls -l ./1412233213.M638209P10546
> ls: cannot access ./1412233213.M638209P10546: No such file or directory
>
> Any suggestions?
>
Does "ls -l *546" show the file to exist? e.g. what happens if you use
the exact same wildcard in the ls command as you used in the find?
It is possible (and back in the day it was quite common) for files to be
created with non-renderable nonsense in the name. for instance if the
first four characters of the name were "13^H4" (where ^H is the single
backspace character) the file wold look like it was named 14* but it
would be listed by ls using "13*". If the file name is "damaged", which
is usually a failing in the program that created the file, then it can
be "hidden in plain sight".
Note that this sort of name is hidden from the copy-paste done in the
terminal window because the binary nonsense is just not in the output
any more by the time you select it with the mouse.
It doesn't have to be a backspace, BTW, it can be any character that the
terminal window will not render.
If things get really ugly you may need to remove the file using
find . -name "*546" -exec rm "{}" \;
(This takes the wildcard expansion out of the hands of the shell and
makes it happen in the find command, which may have different
functionality in your build.)
Anyway, this sort of mangled file name can happen in any file system as
the various binary and non-printable name elements are completely legal
in the POSIX standard.
-- Rob.
next prev parent reply other threads:[~2014-10-18 13:33 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-18 3:54 strange 3.16.3 problem Russell Coker
[not found] ` <CAHGunUkzXZ-ybUR_y3tHzGwtn_45gq8YQJyEqteBX3zqWzUakA@mail.gmail.com>
2014-10-18 10:29 ` Russell Coker
2014-10-18 13:33 ` Robert White [this message]
2014-10-18 23:41 ` Russell Coker
2014-10-19 5:37 ` Duncan
2014-10-19 10:19 ` Duncan
2014-10-20 17:37 ` Robert White
2014-10-20 20:21 ` Goffredo Baroncelli
2014-10-21 9:50 ` Duncan
2014-10-21 10:16 ` inode_cache " Roman Mamedov
2014-10-21 12:08 ` Duncan
2014-10-21 16:40 ` Goffredo Baroncelli
2014-10-22 7:12 ` Duncan
2014-10-19 10:46 ` Chris Samuel
2014-10-20 4:38 ` Duncan
2014-10-20 13:02 ` Zygo Blaxell
2014-10-20 13:19 ` Austin S Hemmelgarn
2014-10-21 10:13 ` Russell Coker
2014-10-21 10:42 ` Russell Coker
2014-10-21 15:23 ` strange 3.16.3 problem (er... never mind 8-) Robert White
2014-10-21 12:25 ` strange 3.16.3 problem Duncan
2014-10-21 15:10 ` Robert White
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54426C16.5030206@pobox.com \
--to=rwhite@pobox.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=russell@coker.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.