I have been running a Perforce server on a free tier (30gb) EC2 instance on AWS. I use it for hobby projects in Unreal Engine.
I wanted to fully delete a project + its depot, to free up space. I have done this in the past successfully, and so attempted the same method: first running "obliterate" on the depot from within P4Admin (using context menus) as instructed by documentation.
But when I tried to then delete the depot itself I got errors claiming there were still files in the depot. But I could not see any files, the folder in explorer and depot tree was entirely empty.
It also told me that I could bypass this error by running 'p4 depot -d -f depotname', which I did through Windows CLI. It reported success, and the depot is indeed now gone from P4V visual client and that folder completely empty on my computer.
However, my EC2 instance still shows 6.8/30GB in use (the amount in use before deletion). I can't figure out how to get it to recognize or "sync" with the fact that this depot has been deleted.
When I list files on the EC2 I see this: results of ls command
That "depot" highlighted in blue I can only assume IS the depot that's supposed to be deleted, but it's still there.
Running any p4 commands withing the EC2 itself gets:
-bash: p4: command not found
Please give any advice at ELI5 level. I don't have a background in server admin stuff. Thanks for any help.
But when I tried to then delete the depot itself I got errors claiming there were still files in the depot. But I could not see any files, the folder in explorer and depot tree was entirely empty.
There are a whole bunch of different "views" of the depot (i.e. different sets of files that you might be talking about when you talk about "depot files") and it sounds like you might be looking at one while trying to diagnose the other. These are the three that I think are relevant:
The depot files that you currently have synced to your local workspace. (When you say "folder in explorer", I assume you're talking about files in a Windows workspace, not the files on the actual EC2 server.) This will only be one (or no) revision of the actual depot files, depending on what exactly you've synced.
The files that are tracked in the server metadata as logically belonging to that depot. This is what you see when you look at the "depot tree" in P4V, or when you run p4 files //depot/... at the command line. Each depot file has multiple revisions.
The "archive files" on the server that are the source of truth for the actual file contents. These are the files that actually take up space on EC2. Sometimes the files in one depot will actually be references ("lazy copies") from a different depot -- it is possible for //depot/... to have a million files in the depot tree and no archive files at all in the corresponding server folder -- or vice versa!
If you obliterate a depot and then can't delete it because there are still archive files (I think the actual error message will specify "archive files" as opposed to "depot files" -- this is an important detail!), it means that some other depot has files with references to the obliterated depot's archive files; if you were to delete that depot, those references become invalidated and you end up losing content from the other depot that you weren't trying to delete.
With all that explanation out of the way, here is the fix (assuming you're trying to delete the depot called depot):
p4 snap //... //depot/...
p4 depot -d depot
rm -rf depot
The p4 snap command turns the "lazy copies" into actual duplicated archives; this will basically just take that 8GB that was under the depot directory on your server and copy it into whatever other depot has a dependency. You only ever want to use that snap command if you're planning to rm -rf the folder you just "snapped". Once you've snapped the archives, p4 depot -d shouldn't complain about existing files any more.
The actual rm -rf needs to be run on EC2. Snapping doesn't actually delete the archive files, it just copies them, so you need to delete them from the filesystem. Once the depot has been snapped and deleted this is perfectly safe.