A pervasive recidivist. 5kb "?" file that resists to everything included chlorine.
I have in my home directory a file, it appeared the 6th of November. I do not recall anything special. It is owned by root: [code] ls -l ? -rw-r--r-- 1 root root 5 6 nov 16.15 ? [/code] you cannot change the name to "?", it is 5 Bite of size, you cannot open it with kate e.g. to read or see the content. But you can: [code] sudo cat /home/entropia/? 9427 [/code] "9427"?? What could this be? A damage to the file system? Need to run fsck? And why I cannot, even as root eliminate it? Could it be related to the use of bleachbit? I did run bleachbit as superuser on the system. But even if, it should not have created such a weird thing. The file system: [code] sudo lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 477G 0 disk ├─sda1 8:1 0 399M 0 part /boot └─sda2 8:2 0 476,6G 0 part └─cr-auto-1 254:0 0 476,6G 0 crypt ├─system-swap 254:1 0 7,6G 0 lvm [SWAP] ├─system-root 254:2 0 59G 0 lvm / └─system-home 254:3 0 410G 0 lvm /home [/code] one only disc ssd.
On Fri, 05 Feb 2021 10:07:59 +0100 Stakanov <stakanov@disroot.org> wrote:
I have in my home directory a file, it appeared the 6th of November. I do not recall anything special. It is owned by root: [code] ls -l ?
-rw-r--r-- 1 root root 5 6 nov 16.15 ?
[/code]
What is the file actually called? The output doesn't match that of a file called '?' $ touch ? $ ls -l ? -rw-r--r-- 1 dhoworth users 0 Feb 5 11:08 '?' Maybe try $ find . -maxdepth 1 -type f -exec sh -c 'printf "%-10s %s\n" "$1" "$(printf "$1" | xxd -pu )"' None {} \;
you cannot change the name to "?",
What commands do you use to try this exactly?
it is 5 Bite of size, you cannot open it with kate e.g. to read or see the content. But you can:
[code] sudo cat /home/entropia/?
9427 [/code]
"9427"??
What could this be? A damage to the file system? Need to run fsck? And why I cannot, even as root eliminate it?
Please show the actual commands you use to try to delete the file.
Could it be related to the use of bleachbit? I did run bleachbit as superuser on the system. But even if, it should not have created such a weird thing.
The file system: [code] sudo lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 477G 0 disk ├─sda1 8:1 0 399M 0 part /boot └─sda2 8:2 0 476,6G 0 part └─cr-auto-1 254:0 0 476,6G 0 crypt ├─system-swap 254:1 0 7,6G 0 lvm [SWAP] ├─system-root 254:2 0 59G 0 lvm / └─system-home 254:3 0 410G 0 lvm /home [/code] one only disc ssd.
In data venerdì 5 febbraio 2021 12:15:30 CET, Dave Howorth ha scritto:
On Fri, 05 Feb 2021 10:07:59 +0100
Stakanov <stakanov@disroot.org> wrote:
I have in my home directory a file, it appeared the 6th of November. I do not recall anything special. It is owned by root: [code] ls -l ?
-rw-r--r-- 1 root root 5 6 nov 16.15 ?
[/code]
What is the file actually called? The output doesn't match that of a file called '?' The file is actually called "Questionmark". It is not possible to give it a name, so I think the ? is actually a joker for missing file name.
$ touch ? touch ? touch: impossibile fare touch di ''$'\320': Permesso negato touch "?" goes back to prompt.
$ ls -l ? finds actually two files: -rw-r--r-- 1 entropia users 0 5 feb 14.03 ? -rw-r--r-- 1 root root 5 6 nov 16.15 ?
$ find . -maxdepth 1 -type f -exec sh -c 'printf "%-10s %s\n" "$1" "$(printf "$1" | xxd -pu )"' None {} \;
you cannot change the name to "?",
What commands do you use to try this exactly? I tried to do this in dolphin, super user mode.
it is 5 Bite of size, you cannot open it with kate e.g. to read or see the content. But you can:
[code] sudo cat /home/entropia/?
9427 [/code]
"9427"??
What could this be? A damage to the file system? Need to run fsck? And why I cannot, even as root eliminate it?
Please show the actual commands you use to try to delete the file. "eliminate" in Dolphine as superuser.
with [code] unlink /home/entropia/? unlink: operando "/home/entropia/\320" in più [/code] were "in più" is Italian locale and says: "extra operand" Trying su - and then unlink: # unlink /home/entropia/? unlink: extra operand ‘/home/entropia/\320’ ok, so "in più is "extra operand" So the issue is: is ? actually a filename or a joker? when you cat the file then the content it shows is the number 9427. Trying with rm: # rm /home/entropia/? And that worked! So it remains to ask for me: why would dolphin as superuser not work? (Showed permissions but could not change them and could not change name, etc). why unlink did not work while rm /home/entropia/? worked? rm is for me a bit a scary command as it can erase the whole home directory with a typo (or am I wrong?). And second question: what kind of origin could this file have? Content "9427" does not make any sense to me. So it must be some "lot and found" or similar thing.
On 05/02/2021 14.20, Stakanov wrote:
In data venerdì 5 febbraio 2021 12:15:30 CET, Dave Howorth ha scritto:
On Fri, 05 Feb 2021 10:07:59 +0100
...
Please show the actual commands you use to try to delete the file. "eliminate" in Dolphine as superuser.
with [code] unlink /home/entropia/? unlink: operando "/home/entropia/\320" in più [/code]
were "in più" is Italian locale and says: "extra operand"
Trick. Create this script: cer@Telcontar:~> cat /usr/local/bin/ingles #!/bin/sh LANG=en_US.UTF-8 \ LC_ALL=en_US.UTF-8 \ DICTIONARY=english \ KDE_LANG=en_US.UTF-8 \ LANGUAGE=en_US.UTF-8:en \ exec "$@" cer@Telcontar:~> Then you can do: ingles unlink /home/entropia/? and the result will be in English and everybody here can read it ;-)
Trying with rm: # rm /home/entropia/?
And that worked!
Notice that this deletes any (and all) files named as a single letter in the directory.
So it remains to ask for me: why would dolphin as superuser not work? (Showed permissions but could not change them and could not change name, etc).
My first suspicion would be partition needs fsck. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
Carlos E. R. wrote:
Trick.
Create this script:
Normally prefixing commands with LC_ALL=C will suffice I think. -- Per Jessen, Zürich (11.6°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland.
On 05/02/2021 14.58, Knurpht-openSUSE wrote:
Op vrijdag 5 februari 2021 14:52:16 CET schreef Per Jessen:
Carlos E. R. wrote:
Trick.
Create this script: Normally prefixing commands with LC_ALL=C will suffice I think. even LANG=C is enough.
Sure. But prefixing the command with "english" is easier to remember :-) A single setting such as LC_ALL or LANG normally suffices, but not in all cases, so I cover more cases. Test against KDE applications, for instance. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 05.02.21 14:47, Mark Hounschell wrote:
On 2/5/21 8:20 AM, Stakanov wrote:
Trying with rm: # rm /home/entropia/?
And that worked!
It may have worked but it also deleted all files with a one character filename like a b c ....
To prevent that, I use "rm -i ..." where it prompts me for every file it wants to remove and I can say "no" until the offending file is removed and then just ^C the "rm" command. Josef -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
On Fri, 5 Feb 2021 08:47:05 -0500 Mark Hounschell <markh@compro.net> wrote:
On 2/5/21 8:20 AM, Stakanov wrote:
Trying with rm: # rm /home/entropia/?
And that worked!
It may have worked but it also deleted all files with a one character filename like a b c ....
Well it would have if there were any, but there weren't. He earlier ran $ ls -l ? and it only returned the one problemtic result. AS Josef says, the -i option makes things safer if you're doubtful.
Regards Mark
Stakanov, et al -- ...and then Stakanov said... % % I have in my home directory a file, it appeared the 6th of November. I do not % recall anything special. It is owned by root: % [code] % ls -l ? % % -rw-r--r-- 1 root root 5 6 nov 16.15 ? % % [/code] [snip] Although much of this is now moot since it's gone, and so I won't delve into 5kb vs 5b, note that you can ls -l | cat -v to see the not-usually-visible actual file name as expressed in octal. Have a look at that flag in the man pages for more :-) I'm on a phone right now or I'd set up some test cases to show you. And, yeah, watch out for rm and ? globbing and perhaps eating files you didn't mean to :-/ HTH & HAND :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt
On 2021-02-05 9:21 a.m., David T-G wrote:
Although much of this is now moot since it's gone, and so I won't delve into 5kb vs 5b, note that you can
ls -l | cat -v
to see the not-usually-visible actual file name as expressed in octal.
on the other hand RTFM LS(1) -b, --escape print C-style escapes for non-graphic characters -- “Reality is so complex, we must move away from dogma, whether it’s conspiracy theories or free-market,” -- James Glattfelder. http://jth.ch/jbg
Anton, et al -- ...and then Anton Aylward said... % % On 2021-02-05 9:21 a.m., David T-G wrote: % > ... % > ls -l | cat -v % > % >to see the not-usually-visible actual file name as expressed in octal. % % on the other hand RTFM LS(1) % % -b, --escape % print C-style escapes for non-graphic characters True (well, mine is ls(1) not in caps, but ...), and given that this is GNU/Linux that's fair, but I'm one of those crusty old purists that doesn't typically use GNU extensions since they ain't everywhere. Of course, they're better than many AIX ports that just flat-out change behavior ...*sigh* Besides, my way he gets to learn about, or be reminded of, something that works for more than just ls of a file name :-) Thanks & HAND :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt
On Fri, 5 Feb 2021 10:40:16 -0500 David T-G <davidtg-robot@justpickone.org> wrote:
Anton, et al --
...and then Anton Aylward said... % % On 2021-02-05 9:21 a.m., David T-G wrote: % > ... % > ls -l | cat -v
Out of interest I did $ touch '? ?' $ ls -l ??? | cat -v -rw-r--r-- 1 dhoworth users 0 Feb 5 15:50 ? ? so I don't know what's supposed to happen? OTOH $ ls -lb ??? -rw-r--r-- 1 dhoworth users 0 Feb 5 15:50 ?\n? $
% >to see the not-usually-visible actual file name as expressed in octal. % % on the other hand RTFM LS(1) % % -b, --escape % print C-style escapes for non-graphic characters
True (well, mine is ls(1) not in caps, but ...), and given that this is GNU/Linux that's fair, but I'm one of those crusty old purists that doesn't typically use GNU extensions since they ain't everywhere. Of course, they're better than many AIX ports that just flat-out change behavior ...*sigh* Besides, my way he gets to learn about, or be reminded of, something that works for more than just ls of a file name :-)
Thanks & HAND
:-D
Hello, On Fri, 05 Feb 2021, Dave Howorth wrote:
Out of interest I did
$ touch '? ?' $ ls -l ??? | cat -v -rw-r--r-- 1 dhoworth users 0 Feb 5 15:50 ? ?
so I don't know what's supposed to happen?
Actually, the file was not named '?' but named 'Ð', i.e. Oct Dec Hex Char Description 320 208 D0 Ð LATIN CAPITAL LETTER ETH (from man latin1 / man latin9). So, you'd need to do: $ touch $'\320' $ ls -b \320 And if you're using an ASCII or UTF-8 locale that single byte name is not a valid character, which might explain the problems deleting it. Using 'LC_ALL=en_US.latin1 rm -vi' might help. HTH, -dnh PS: I guess it'd be best to force this mail to be utf8 encoded, so it does not sound all ελληνικά to you ;) -- program (pro'-gram) [n] A magic spell cast over a computer allowing it to turn one's input into error messages. tr.v. To engage in a pastime similar to banging one's head against a wall, but with fewer opportunities for reward.
On Fri, 5 Feb 2021 22:28:11 +0100 David Haller <dnh@opensuse.org> wrote:
Hello,
On Fri, 05 Feb 2021, Dave Howorth wrote:
Out of interest I did
$ touch '? ?' $ ls -l ??? | cat -v -rw-r--r-- 1 dhoworth users 0 Feb 5 15:50 ? ?
so I don't know what's supposed to happen?
Actually, the file was not named '?' but named 'Ð', i.e. Oct Dec Hex Char Description 320 208 D0 Ð LATIN CAPITAL LETTER ETH (from man latin1 / man latin9).
Sorry, I have no idea what you're trying to tell me. I already knew and had said earlier that the original file was not called '?'. So I don't need to be told that, and I don't think we've seen enough information on list to know exactly what it was called, so I *would* be interested to know how you come to know it. But what I was commentiong on was that cat -v apparently doesn't substitute for a newline in a filename which (a) I'd expected and (b) makes ls -b a clear winner in this situation IMHO.
So, you'd need to do:
$ touch $'\320' $ ls -b \320
And if you're using an ASCII or UTF-8 locale that single byte name is not a valid character, which might explain the problems deleting it.
Using 'LC_ALL=en_US.latin1 rm -vi' might help.
HTH, -dnh
PS: I guess it'd be best to force this mail to be utf8 encoded, so it does not sound all ελληνικά to you ;)
On 06/02/2021 13.06, Dave Howorth wrote:
On Fri, 5 Feb 2021 22:28:11 +0100 David Haller <dnh@opensuse.org> wrote:
...
Actually, the file was not named '?' but named 'Ð', i.e. Oct Dec Hex Char Description 320 208 D0 Ð LATIN CAPITAL LETTER ETH (from man latin1 / man latin9).
Sorry, I have no idea what you're trying to tell me. I already knew and had said earlier that the original file was not called '?'. So I don't need to be told that, and I don't think we've seen enough information on list to know exactly what it was called, so I *would* be interested to know how you come to know it.
He got it from this Stakanov post:
]> $ touch ? ] touch ? ] touch: impossibile fare touch di ''$'\320': Permesso negato ] touch "?" goes back to prompt. or these: ] with [code] ] unlink /home/entropia/? ] unlink: operando "/home/entropia/\320" in più ] [/code] ] ] were "in più" is Italian locale and says: "extra operand" ] ] Trying su - and then unlink: ] # unlink /home/entropia/? ] unlink: extra operand ‘/home/entropia/\320’ ] I missed the importance of those error messages. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
participants (13)
-
Anton Aylward -
Bernhard Voelker -
Carlos E. R. -
Carlos E.R. -
Dave Howorth -
David Haller -
David T-G -
Josef Moellers -
Knurpht-openSUSE -
Mark Hounschell -
Per Jessen -
Simon Becherer -
Stakanov