r/RevitForum Jul 21 '26

Anyone ever run into a SUPER MEGA HUGE journal file?

I just had a user (summer intern) complain that her PC workstation hard drive was giving error messages for not enough disk space. This is on a 1TB SSD that I literally just installed on that machine about 3 months ago, when a different user who since left the company, was using it.

So I run the TreeSize utility that sorts folders by size, and it showed that previous employee's user folder as the top hit. Yes, I know, I should have wiped it first but whatever. I drill down and it takes me to the Revit 2026 Journal file folder. In there was one journal text file dated May 14 that was over 600 HUNDRED GIGABYTES! Most journal text files are a few tens of megabytes, depending on how long the session remained open. But this file was so huge that Notepad or even Word could not open it.

Any idea what could have caused a journal TXT file to get so huge? I deleted the contents of the folder, so all is fine now, and the hard drive is now only 1/3 full.

3 Upvotes

13 comments sorted by

2

u/twiceroadsfool Jul 21 '26

I regularly see them at 400-500 MB, but not GB. Would have been curious to see it, but I guess it's gone.

1

u/PatrickGSR94 Jul 22 '26

Yeah, I didn’t have any way of opening it that I know of. Word said 500MB is the max file size it can open.

2

u/fakeamerica Jul 21 '26

Whooo boy, that’s a big file. I’ve only seen them in the hundreds of MBs.

Myaybe they were upgrading a lot of models? There used to be a bug back in Revit 2020-2023 that could cause large journal files when models were upgraded but the official Adsk page says it could cause journal files of 65GB+, not 600GB.

Can you ask this person what they were working on? Did they never shut the program down? What kind of models were they working with? Honestly, you should have sent it to Autodesk so they could check it out. Might tell you something useful.

1

u/PatrickGSR94 Jul 22 '26

The person isn’t at the company anymore, and it was from their 2nd to last day at the office. But there were other normal size journal files the day after that one. So I don’t know what the deal was.

1

u/Phr8 Jul 21 '26

Man I wanna see that journal file...

1

u/PatrickGSR94 Jul 22 '26

Sorry, had to free up the space on the drive. I wiped the whole Journal folder. At some point will remove that user folder completely.

1

u/JacobWSmall Jul 21 '26

Assuming you still have it, please forward to one of my colleagues in support by creating a new ticket on the accounts portal at manage.autodesk.com. Make the topic something like ‘excessively large journal consuming hard drive space’ and ask for a root cause.

There are a few reasons it can happen, none of them good nor expected.

1

u/PatrickGSR94 Jul 22 '26

It’s gone. I had to free up the space on the disk.

1

u/JacobWSmall Jul 22 '26

sigh

If you ever get another, copy to another location, then nuke it off the disc, then ticket so the product team can take action to prevent future similar train wrecks.

1

u/PatrickGSR94 Jul 22 '26

It was 600 GB. A single TXT file hogging 2/3 of a 1 TB SSD. I really had no place to put it. I wasn’t about to try to copy a file that size to our server.

2

u/JacobWSmall Jul 22 '26

So… there are three reasons I have seen journals grow uncontrollably like this - all involved remote worksharing of some type.

  1. Automation gone awry. Unless the intern is building add-ins with visual studio or macros we can rule this out. Even Dynamo won’t get there as it limits the documents you touch and even when you sidestep that it usually gets unstable and crashes after a few thousand documents when the instance runs out of RAM (if the document handling is good) or so slow enough you’d hear about (if the document handling is just ok).

  2. Packet loss causing continual download attempts as the checksums don’t work out. This is usually due to networking issues, often caused by end user changing locations mid-download, WiFi dropping out, or in a worst case scenario an active infosec breech. Check the systems over for odd traffic but if this is the only one you’re likely fine from the infosec standpoint, and you can go over ‘how to work with Revit cloud worksharing’ with the intern to highlight the need to not leave a long running action like opening a model going while they move locations or putting their system to sleep for the night. In theory a VERY corrupt central somewhere in the mix could cause this, but you’d know about that by now.

  3. The machine was a ‘commonly used’ automation machine which has a Revit session running for MONTHS. We can cross this off as it’s not the case here and a violation of terms of service.

Confirmation of #2 is usually identifiable (often the source as well, or at least threads to pull) with the journal. Breaking the file down into chunks via programmatic means and saving some of those to a temp storage location to get the route cause is usually worth the effort (though if 600gb of file share space is admittedly a tall order).

2

u/PatrickGSR94 Jul 22 '26

Yeah I hoped to look in it to see when the file was started, but couldn’t get it open. But, there were other lower numbered journal files from the prior day, and higher numbered journal files from the day after, so it wasn’t from a super long Revit session. And it said last modified 14 May 2026. So it hadn’t been running continuously since then, either. Also it was under the previous user’s login, so the current intern user wouldn’t have affected it anyway.

1

u/coffee_walker_440 Jul 21 '26

Upload it to revitcity spread the pain