graphisoft cache policy (mac)

[schagemann]

just the other day i happened to investigate what takes the most space on my HD... and guess what, one of the major congestors (apart from the itunes library) seem to be the archicad cache files.

/Users/Daniel/Library/Caches/Graphisoft/ArchiCAD Cache Folder

so i went around and had a look at a few other macs in the office and found the following: on average the cache files take up around 2 GB - one computer even had 11 GB worth of archicad caches. to me this looks as if archicad does not delete the cache files on exit...

however, i wonder what the reason for this might be?
has anyone else had that problem before?
was this bug, if it is one, resolved in any of the recent versions?

daniel.

[__archiben]

schagemann wrote:
so i went around and had a look at a few other macs in the office and found the following: on average the cache files take up around 2 GB - one computer even had 11 GB worth of archicad caches. to me this looks as if archicad does not delete the cache files on exit...

however, i wonder what the reason for this might be?
has anyone else had that problem before?
was this bug, if it is one, resolved in any of the recent versions?

daniel.

mm. good stuff, eh? and not a 'restore' tool in sight to make use of them.

i do seem to remember being told that this was cached data that archiCAD stores about a project file during a session and from one session to another . . so that 3D rebuild times (for example) are quicker because only the information changed needs recalculating. i don't know how accurate this is, or recall where it came from!

i regularly check and purge this data myself now - remember to do it only when archiCAD/plotmaker are quit.

it may be worth formally asking GS what their policy is about this . . . and maybe lászló nagy can write us another archiGUIDE article?

~/archiben

[Anonymous]

I had the same problem with AC 8.1.0 v1 (1443)
Because AC did not delete the cache files, i had to do it myself.
It seems that a lot of Mac users were concerned,
and i feel some other did not realize the problem.

This is solved now (for me) with AC 8.1.0 v2 (2284)

[Greg Kmethy]

The ArchiCADGdlBinCode.dat file is the only one that is supposed to stay there after you quit ArchiCAD. This contains the compiled binary code of all the previously used GDL objects, therefore it makes library part handling faster if you have this file. If you delete it, it will be re-created when you run ArchiCAD the next time. It usually does not grow larger than 2-3 Megs, but it depends on how many libparts you regularly use.
All the other files can be deleted if they are stuck there. In an early version of ArchiCAD 8 there was a bug that left unnecessary files here, but it was fixed in ArchiCAD 8 R2 or R3.

HTH,
Greg

[Anonymous]

Has this problem been solved in AC9?

[Eduardo Rolon]

Checked mine besides ArchiCADGdlBinCode.dat being 11 megs I had a bunch of scratch files (up to 500Mb worth) this is on AC 09

[Anonymous]

I hadn't noticed the scratch files in the cache folder until I started to get HD Full messages yesterday...... I have scratch files in both the AC9 and AC10 cache folders.... Is there anything I can do to stop accumulating them?

[__archiben]

SteveC0013 wrote:
Is there anything I can do to stop accumulating them?

when archicad crashes it doesn't get to clean things up in the way it would if it was able to run through its usual 'quit' process. maybe it should check for 'out-of-date' caches on startup too?

if archicad crashes you may need to check manually for the caches it leaves behind: but beware . . . if you have multiple archicad sessions open, some of the cache files may still be live. if you are deleting them ensure that all archicad sessions have been quit first . . .

~/archiben

[schagemann]

... and it still is a problem with AC10.

however, as AC10 files are now considerably smaller in size the scratch files are smaller too... ;0)

i still think that graphisoft ought to resolve the problemsometime - given that this is now around for some versions... to be continued.