Large library size

[hryamzik]

du -hs ~/Library/Application\ Support/com.github.atom.ShipIt/
9.0G

And there're 45 update.** files inside, 203M each. Seem to be a cleanup issue.

P.S.: Mac OS 10.10.3

[lee-dohm]

Looks like this isn't confined to the Mac:

https://discuss.atom.io/t/com-github-atom-shipit-is-using-10-gb-of-space/18461

[friday]

This happened to me recently with Avast, and now with Atom (13 gb). So I guess my permissions might be set up "strangely". What should they be set to?

[ptica]

2015-07-16 11:47:26.167 ShipIt[2380:1595531] Couldn't remove owned bundle at location file:///var/folders/57/pnpcvx2x62v4y48q575rmddr0000gn/T/com.github.atom.ShipIt.eeg3K3Ls/Atom.app, error NSError { domain: NSCocoaErrorDomain, code: 4, description: "“Atom.app” couldn’t be removed.", failureReason: "The file doesn’t exist.", underlying error: NSError { domain: NSPOSIXErrorDomain, code: 2, description: "The operation couldn’t be completed. No such file or directory" }, userInfo: {
    NSFilePath = "/var/folders/57/pnpcvx2x62v4y48q575rmddr0000gn/T/com.github.atom.ShipIt.eeg3K3Ls/Atom.app";
    NSUserStringVariant =     (
        Remove
    );
} }

[ptica]

but the good news is that I've updated to 1.0.2 just now and the ~/Library/Application\ Support/com.github.atom.ShipIt/ got pruned to nearly zero!

[mgoffin]

I'm on 1.0.2 and just had this problem 14G of space used which filled the rest of my disk space.

[kellyjandrews]

Same here - I'm currently at 8.9GB. Can we just delete these?

[mgoffin]

Yep! I just nuke update.* and wait til it fills up again.

[LeviSchuck]

Ugh.. Seriously, so this is why I kept having to move stuff off my main boot partition.

16GB of past update stuff is irresponsible to leave around.

[kellyjandrews]

@mgoffin Seems legit..... 👎

[kevinsawicki]

/cc @joshaber @robrix @keithduncan any ideas on this one from a squirrel point of view? Appreciate any help or insight you might have.

[LeviSchuck]

The updates are being accumulated, one after another, and when atom is shut down or started, don't know which, it applies the latest update and then deletes them all (On OSX at least)
However, if updates happen and you don't close Atom for a long time, it just keeps downloading more and more, without cleaning out the update directory, even though it doesn't destroy outdated updates.

[joshaber]

@kevinsawicki Do we know what version of Squirrel we're using? It looks like we're downloading the framework pre-built from https://github.com/atom/atom-shell-frameworks/releases, but it's not clear what version of the framework that would be.

Squirrel/Squirrel.Mac#103 should, in theory, address what @LeviSchuck outlines above. But without knowing the Squirrel version we can't know if atom just needs to pick that fix up, or if there's something else going on.

[kevinsawicki]

@joshaber thanks for the details, @zcbenz do you know which version of Squirrel Electron is using currently?

[zcbenz]

I think we are using 0.1.5, which is released 6 months ago.

[joshaber]

In that case you'd definitely have Squirrel/Squirrel.Mac#103.

For those of you who get a bunch of updates built up, it'd be really great if you could save your ShipIt_stdout.log and ShipIt_stderr.log and paste them in here.

[friday]

@joshaber

My ShipIt_stdout.log is 0 bytes.
ShipIt_stderr.log seems to have relevant info, but the wrong path? http://pastebin.com/0x50SnaC

[joshaber]

Thanks @friday! 🤘

I'm adding this to my list to investigate.

[StevenEWright]

+1

23.1 GB of space consumed.

[jacobtomlinson]

+1 4.4GB used

[benharold]

I had this issue (approx 9 GB) but after quitting Atom and restarting my computer, the size of that directory went down to 8 KB (version 1.0.11).

[cbess]

Same issue here, was 4GB (v1.0.11). When I restarted Atom (quit the app on Mac), it cleared the directory out.

[joshaber]

I haven't been able to reproduce this personally yet.

One of my current theories is the app is sometimes quit & restarted before the app has the chance to perform the update. This is because there's a lengthy validation process that happens after downloading the update and before applying it. So then the app is launched again by the user, it downloads the update again, etc. This keeps happening until the app is quite for long enough for the update to apply and clean up.

For those of you who have experienced this, does that make sense with what you see? Or does that sound like nonsense?

[mgoffin]

To reproduce: open Atom and never close it.

[joshaber]

Has anyone seen this recently?

[BusterNeece]

@joshaber Can verify that this is still happening as of Atom 1.3.2. Only very recently installed Atom on my Mac, left it running in the background through a few wake/sleep cycles, came back to a "disk space usage" warning with 15GB of space taken solely by the ~/Library/Application\ Support/com.github.atom.ShipIt/ folder. Cleaning up the folder seems to be without side effect, as the app launched fine anyway and didn't try to repopulate the giant folder.

[lokenx]

Any idea if this is still an issue? Just realized mine is 79 GB (!?) on OS X 10.10.5 and Atom 1.3.3.

Is it safe to just delete all these files, or should I keep them around for now testing (I've 20 GB free still on my 256 GB SSD so I don't need to clear the space just yet).

[joshaber]

@lokenx It looks like some people are still experiencing it unfortunately 😞 Feel free to delete all those files.

[lokenx]

OK thanks! I'm glad I noticed before my disk ran out of space 😟

Regardless, keep up the good work!

Edit: it seems to have cleared itself up, not sure if it was restarting or opening Atom or what.

[joshaber]

@lokenx Oh interesting! Had you launched/restarted Atom in a while?

[lokenx]

I don't believe so. I'd been off work for a number of months (broken knee). The machine was on but not in use, and no one else uses. I started Atom to get the version number off it and then closed down--maybe that was enough. It was already on 1.3.3 without me updating either (background updates?).

[seangates]

Mine is 4.3GB. Atom v1.6.2. Will this be addressed soon?

[lee-dohm]

@seangates How did you install Atom? Have you not restarted Atom recently?

[seangates]

@lee-dohm I have had it open for a few days, as I usually go a few weeks without restarting it. Is that part of the issue?

Also, I originally installed it about a year ago, and have been getting regular automatic updates over time, whenever I have restarted my machine.

[lee-dohm]

Well, the latest version is v1.7.2. I'm not sure when it clears out the old versions that have been downloaded. So if you're not restarting I assume it could be downloading multiple new versions and not clearing them out until the restart happens?

[seangates]

@lee-dohm Let me restart Atom and see if the large file persists.

[gerrywastaken]

@lee-dohm I just ran Atom/Update and Restart. During the update I watched the updates directory. A new directory called update.15SjUvX was created and then deleted shortly after.

I'm not sure about the initial conditions that lead to update files building up in the directory. However this is a good sign.

[seangates]

The issue persists. The file is still 4.31GB after restart on v1.6.2. I'm updating to v1.7.2 to see if it solves the issue.

[seangates]

Yeah, updated to v1.7.2, still have a 4.31GB ShipIt_stderr.log file.

[gerrywastaken]

@seangates I didn't think this issue was ever about the stderr.log file being too big. I believe it was about having many redundant update directories which were massive. Not having pruning on the error log is another issue which I don't believe has been mentioned here until your comment.

[seangates]

@gerrywastaken Okay. Should there be a new issue raised?

[gerrywastaken]

@samlambert Yes, or looking at what was in the error log. Perhaps that points to something that should be fixed? Part of me thinks that it's a good thing that the error log grows large, because then at least it grabs attention.

If it's stuff that is no longer relevant then it probably shouldn't be filling up the hard drives of people who haven't realised what the issue is.

I'm not a maintainer so I'll defer to @nathansobo, who closed this issue, so probably knows what should be done regarding the error log file size.

[seangates]

@gerrywastaken Well, since it was an error log ... I deleted it. So, I don't know what's in it anymore. But, I assume it was simply for logging purposes to diagnose issues. The fact that it was over 4GB is concerning, though, as it should be pruned periodically. Or the log should be broken in to date ranges and pruned according to date ranges, like the last 5 days or something. (Configurable, maybe?)

Anyhow, it looks like my issue is different that stated in this issue, so I'll stop replying. 😉

[gerrywastaken]

@lee-dohm Since my comment 29 days ago: #7061 (comment)

The directory has started filling up again.

Closing Atom does remove a lot of the data from inside the "update.djksja" directories, but if the user needs to periodically restart Atom, I'm not sure that is a great default behaviour. It does also leave the directories in place. I'm not sure if this is expected.

[ahundt]

I still have this problem as well, I'm trying to figure out how to simply delete atom so it stops and I can't figure that out either!

[ahundt]

I haven't been able to totally remove atom (which I would like) but I've been able to get the log to stop printing with:

 launchctl stop com.github.GitHub.ShipIt

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[lock]

This issue has been automatically locked since there has not been any recent activity after it was closed. If you can still reproduce this issue in Safe Mode then please open a new issue and fill out the entire issue template to ensure that we have enough information to address your issue. Thanks!