protonscr

files with garbled filenames in steam directory (invalid encoding)

steamclosed
ValveSoftware/steam-for-linux#6922 · opened 2020-02-23 by fallenguru · updated 2023-12-20 · 10 comments · github
Ffallenguru 2020-02-23 github

Your system information

  • Steam client version (build number or date): 2020-02-21
  • Distribution (e.g. Ubuntu): Ubuntu 18.04.4
  • Opted into Steam client beta?: Yes
  • Have you checked for system updates?: Yes

Please describe your issue in as much detail as possible:

I find that I have a couple of files with garbled filenames in my steam directory, not on all my machines, but more than one. nautilus postfixes them with "(invalid encoding)" [in German, because of course it ignores LANG, sorry]. Any ideas?

invalid encoding (ls)
invalid encoding (nautilus)

?ghost 2020-02-24 github

Does Steam run fine? If it does, why care?

If Steam works and you care that much, then does Steam still run fine once you delete them? Could be that once you delete them that they won't come back.

I'm not sure why files are there like that for you except maybe when writing the names of the files to disk that some package or maybe a bad download or something caused it to happen.

In other words, in code, I would fully expect to write the name eg "thisFile.sh" to disk exactly how I specify. So either the responsible part of the OS caused it to be written incorrectly or the string that was being written to in the code had been borked on reading of it or on download from the internet.

That's how I see it anyway.

Kkisak-valve maintainer 2022-07-15 github

Hello @fallenguru, have you seen this issue reappear with a random gibberish named file dated newer than those described in the initial report?

Ffallenguru 2022-07-28 github

No, as far as I can tell there are no newer ones. Probably just a fluke, then. Feel free to close, I can always re-open if it pops up again.

Kkisak-valve maintainer 2022-07-28 github

Thanks for checking. Closing as unreproducible.

DDrTexx 2023-12-20 github

Earlier today I also noticed 3 files with gibberish invalid encoding filenames under my /home/denver/.steam/debian-installation/ directory, they were:

  • file 1 - �i���`�0
    • in hex: 0xef 0xbf 0xbd 0x69 0xef 0xbf 0xbd 0xef 0xbf 0xbd 0xef 0xbf 0xbd 0x11 0x60 0xef 0xbf 0xbd 0x30
    • last modified: Jul 7th 2019
  • file 2 - �����
    • in hex: 0xef 0xbf 0xbd 0xef 0xbf 0xbd 0xef 0xbf 0xbd 0xef 0xbf 0xbd 0xef 0xbf 0xbd 0x07
    • last modified: Oct 13th 2019 (98 days later)
  • file 3 - }��Mн�*
    • in hex: 0x1c 0x7d 0xef 0xbf 0xbd 0xef 0xbf 0xbd 0x4d 0xd0 0xbd 0xef 0xbf 0xbd 0x2a
    • last modified: Oct 18th 2019 (5 days later)

Importantly though, I wasn't able to find any with gibberish filename encoding after Oct 2019, but I've barely used this machine between then and now, so I'm probably not the best benchmark of if the issue is still happening. Also of note is that I didn't notice any other invalid encoding filenames anywhere else on my system after doing a recursive scan across my whole system with a Python script, so it doesn't seem to be data corruption caused by a hardware fault.

It may be totally unrelated, but I think I might've been playing a lot VR around that time, so there's a chance it was related to SteamVR (which I think was on the linux branch at the time) - but take that with a grain of salt, can't say 100% that's relevant.

Anyhow, just thought I'd make a post with what I experienced and what I know just in case anyone else comes across this GitHub issue like I did, seems to be fairly uncommon.

DDrTexx 2023-12-20 github

If it's useful at all, here's the contents of file 1 in a GitHub gist (in both utf-8 encoding and hex): https://gist.github.com/DrTexx/ae972316e21160ce7238a8258e404767

DDrTexx 2023-12-20 github

Oh and also here are the plaintext strings (ish) I got back when I used the linux strings command on file 1.

Can't seem to gather much info on what's going on, but seems like files named game-[0-2].png are relevant along with %tEXtdate:create 0x00 2013-04-30T15:56:54-07:00 and %tEXtdate:modify 0x00 2013-04-30T15:56:54-07:00

maybe something to do with image paths and file creation/modification date metadata?

in:

~/.steam/debian-installation$ strings ./''$'\274\377\377\377\300\a'

out:

game-0.pngUT	
MMMI		!^na^ni)I
gmW\c
&).&
#sB(a
fG79
le}R
G^jC
(II,I
Bo\}z
game-1.pngUT	
IHDR
PLTE
YeiKMMJJJJIIIII
'0$t
)WmA
;Jy{{
uwwUdj
@FIO
fmpK
tRNS
	pHYs
"IDAT8
o``hdl
88:9
 >!1)
6N*)(
EAYy
mlBQ
Mr)2
7?H5
wssce[
%tEXtdate:create
2013-04-30T15:56:54-07:00
%tEXtdate:modify
2013-04-30T15:56:54-07:00
IEND
game-2.pngUT	
IHDR
PLTE
pqsddd
zzzGGG)))
777,./
		+++
2=9IT
-H0Rpl
221s
llli
N_&h
5>B:
1Q Ei1z
*:K#*+Q
yzzVuz
tRNS
	pHYs
IDATH
sprq
+H)"	KJ@
PQUS
cbbc
E3x 
wn62
UwAt
{7%<by
cMlM
(SP(
%tEXtdate:create
2013-04-30T15:56:54-07:00
%tEXtdate:modify
2013-04-30T15:56:54-07:00
IEND
game-0.pngUT
Bo\}z
game-1.pngUT
game-2.pngUT
DDrTexx 2023-12-20 github

When I tried opening the files in VS Codium, I noticed that somehow it seems like the file preview was able to reveal (at least seemingly) that:

  • file 1: is a thumbnail for the game 'Inside'
  • file 2: is apparently a zip archive, but I can't seem to open it
  • file 3: is a very low-res thumbnail for the game 'Just Cause 3'

(note that in this screenshot the files appear in this order: file 1, file 3, file 2 - They seem to be sorted differently in this window compared to the terminal)

Screenshot from 2023-12-20 21-54-24

DDrTexx 2023-12-20 github

I figured out how to open the final file too! If I add the file extension .zip to file 2, I'm able to open the archive in Debian's archive manager. It appears to be an archive with three different resolution images of the thumbnail for the game 'Portal'.

Screenshot from 2023-12-20 22-28-35

I still don't know why this happened, but at least now I no I've gotten closure on what seems to have been in the files :) (at least what was supposed to be anyhow)

Hoping maybe this can help someone else figure out what's going on too! :slightly_smiling_face:

DDrTexx 2023-12-20 github

Further note: it appears that I can open file 1 and file 3 just fine if I add the .ico file extension :framed_picture:

Nothing extracted yet.