Earlier this morning, it came up in #site19 that the Sandbox III has reached maximum capacity at 5 gb, and no new files can uploaded. Storage for the site must either be increased by Mann, or we'll have to move to a fourth sandbox site.
can I get some nice "no signatures on my forum"
sigma-9 css machine broke
understandable have a nice day
We could also move the pro account to sandbox 1 while we clean up 1 and 2, there’s such a proliferation of supplementary sandbox sites that it seems a bit silly to me to just make more of them.
Sandbox 1 has under 300 mb of storage used, if we upgrade it to 5 gigs and clear out excessively large files from the other two sandboxes we should be good for at least a couple of years.
Whether you like it or not, history is on our side. We will bury you!
I feel it's a Sisyphean task to clear all of the old images out of Sandbox 2 and 3. The result isn't worth the time and effort, as it'd fill up just as quickly as before. Creating a new sandbox is quicker and easier for a solution that will last longer.
Agreeing with this. There is absolutely no reason not to just make another.
Concurring - furthermore, it allows us to have all moderators and admins of the actual wiki be made moderators and admins of the sandbox off the bat. Which I think is a good idea.
Is there a tool or wikidot functionality that would simplify this process by indicating which pages are using the most file space? It seems like a fairly simple task if there is one, but an outsize investment of energy otherwise.
To my knowledge, there is no way to sort this way. Not even with listpages.
I also checked the admin panel and couldn’t find an option. I assumed it was possible to seek out the largest files in some way, if it’s impossible for that to happen then I agree cleaning up II and III is impractical.
I do recall someone in SSSC talking about some sort of tool for identifying large files in the context of sandbox cleanup, if that does exist I would say cleaning up our current sandboxes to extend their lifespan would be a worthwhile endeavor as it would probably be a few pages with excessively large/numerous uploads that could be cleaned up.
Whether you like it or not, history is on our side. We will bury you!
Tech team ran a file size analysis on III a while back, which indicated that there's no pages that are really taking up a lot of space particularly, and the growth of total storage against time is pretty linear. Individual file size limits and upload limits per page ensure that there is no single culprit taking up a lot of space, or even a single user.
The effort required to make a sandbox IV is far less than the effort required to select, notify creators of and remove files from II and III. I'd also wager that increasing the storage limit for I might not be worth the confusion caused by deviating from the current pattern of sequentially increasing sandbox numbers
Edit: we used an external script that uses the wikidot API to check the files of each page. There's no wikidot-native tool that can do that.
Yeah, this is correct. I have the toolset where I could do this again but it's not any particular page or file doing the damage, it's a sandbox, lots of people used it like one, and it ran out of space. Moving on to the next one is really the only thing I can advocate for the results versus the time and effort expended.
Just let me know when we have a new sandbox and I'll switch the pro account to it.
Actually, there is a way, now that I think of it. If you download a backup, you should be able to use that to identify where the large files are. I'm currently on heavily throttled internet, but if someone wants to give that a go, that might be easy enough to accomplish.
The downloaded backups unfortunately do not associate files to specific pages, it's just a jumbled mess.
It should probably be an admin creating the new sandbox (and having the master admin privileges on it).
For now, I've handed Master Admin of Sandbox 2 to Zyn and upped the storage limit on 3 to 10 GB. We'll still need to change it out eventually.
(account deleted)