this post was submitted on 19 Sep 2024
685 points (97.8% liked)

196

16244 readers
1922 users here now

Be sure to follow the rule before you head out.

Rule: You must post before you leave.

^other^ ^rules^

founded 1 year ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 79 points 1 day ago* (last edited 1 day ago) (7 children)

Ok, but the second tweet is a bit redundant

Like what else would a .log file be? A video file? A Word Document? An executable?

Do you really need to inspect the properties to be told: "This .log file is certainly containing text. Thank you for installing Windows 10. Save 5% on your Office 365 subscription with code 'ILOVEMICROSOFT'"

[–] [email protected] 6 points 10 hours ago* (last edited 10 hours ago)

It could be a XML or JSON with some embedded binary data (but to your point Windows isn't gonna figure that out from the extension)

[–] [email protected] 19 points 14 hours ago (2 children)

Like what else would a .log file be? A video file? A Word Document? An executable?

I think their point is that a 200gb text file is a wild size usage for a crash log, and there's probably accidentally some binary data in that log. There's no way a crash log can exceed 2x the size of the game binary itself.

[–] [email protected] 20 points 13 hours ago

Could be a bug in their crash handler, just like, infinitely looping and printing something over and over.

[–] [email protected] 3 points 11 hours ago

Binary data is almost always more compact than text data

[–] [email protected] 78 points 1 day ago* (last edited 1 day ago) (3 children)

You should have rolling log files of limited size and limited quantity. The issue isn't that it's a text file, it's that they're not following pretty standard logging procedures to prevent this kind of thing and make logs more useful.

Essentially, when your log file reaches a configured size, it should create a new one and start writing into that, deleting the oldest if there are more log files than your configured limit.

This prevents runaway logging like this, and also lets you store more logging info than you can easily open and go through in one document. If you want to store 20 gb of logs, having all of that in one file will make it difficult to go through. 10 2 gb log files is much easier. That's not so much a consumer issue, but that's the jist of it.

[–] [email protected] 12 points 15 hours ago (1 children)

As a sysadmin there are few things that give me more problems than unbounded growth and timezones.

[–] [email protected] 1 points 10 hours ago

Printers. Desk phones. Wmi service crashing at full core lock under the guise of svchost.

[–] [email protected] 14 points 1 day ago (1 children)

Fully agree, but the way it's worded makes it seem like log being a text file is the issue. Maybe I'm just misinterpreting intent though.

[–] [email protected] 28 points 23 hours ago (2 children)

200GB of a text log file IS weird. It's one thing if you had a core dump or other huge info dump, which, granted, shouldn't be generated on their own, but at least they have a reason for being big. 200GB of plain text logs is just silly

[–] [email protected] 8 points 22 hours ago (1 children)

no, 200gb of plain text logs is clearly a bug. I run a homelab with 20+ apps in it and all the logs together wouldn't add up to that for years, even without log rotation. I don't understand the poster's decision to blame this on "western game devs" when it's just a bug by whoever created the engine.

[–] [email protected] 5 points 19 hours ago

Agreed, and there's a good chance that log is full of one thing spamming over and over, and the devs would love to know what it is.

[–] [email protected] 1 points 15 hours ago

It could be a matter of storing non-text information in an uncompressed text format. Kind of like how all files are base 0s and 1s in assembly, other files could be "logged" as massive text versions instead of their original compressed file type.

[–] [email protected] 5 points 23 hours ago (1 children)

Essentially, when your log file reaches a configured size, it should create a new one and start writing into that, ~~deleting~~ archiving the oldest

FTFY

[–] [email protected] 4 points 19 hours ago

Sure! Best practices vary to your application. I'm a dev, so I'm used to configuring stuff for local env use. In prod, archiving is definitely nice so you can track back even through heavy logging. Though, tbh, if you're applications getting used by that many people a db logging system is probably just straight better

[–] [email protected] 44 points 23 hours ago (1 children)

I thought they were just trying to hammer home how wild it was for the file to get that big, since it's just a text file.

[–] [email protected] 36 points 23 hours ago

Yeah and also when they said "300gb of crash logs", i assumed it was a folder with thousands of files, instead of all those gbs in a single text file, that's wild

[–] [email protected] 26 points 1 day ago

if you assume the second post has ulterior meaning it could be that someone might not know what a crash log is, but most people who have interacted with computers at least once would be at least vaguely familiar window's file description and understand that text file icon + >200 gb size is not normal

this is, of course, a rather big assumption.
most people don't put that much though in a post and expecting them to will make your online experience a confusing mess.

[–] [email protected] 10 points 1 day ago

Most people have zero understanding of how programs work. I have slightly more understanding than the average person and I didn't catch that a crash log would nearly always be a text file.

[–] [email protected] 9 points 1 day ago

It could be a binary file, though that would probably make it smaller if anything.

I'm guessing the point was the developer didn't invent some proprietary log that also contained a dump and other things that could conceivably be very large. That would also be terrible design, but managing to create hundreds of gigs of text in a game crash log is a special kind of terrible.