How do I remove files that were added to my AWS EC2 instance via perforce, but seem to have been forgotten by perforce?

373 Views Asked by At

Put simply: There are files in my EC2 instance that I need to remove. They were added there by p4 but p4 doesn't seem to be aware of them on the depot. As a result, I'm not sure how to reconcile the local work against the depot's content.

How it happened:

  • I used Helix Core's template in AWS EC2 to set up a fresh server, realizing I needed to get p4 up and running for a project that had outgrown local/manual backups.
  • Once the depot was up and running, I connected to it via p4 and created a workspace.
  • Since this was a preexisting project with many files, I needed to do my initial submit to the depot after reconciling local work.
  • This understandably took a long time and I continued to use the computer for unrelated work in the meantime. During this time, the computer crashed. (This unrelated work involved troubleshooting an unrelated issue that ultimately caused a blue-screen crash when I unplugged a peripheral.)
  • This interrupted the submit abruptly, instead of a proper cancelation.
  • When I was back online, the changelist was still available in p4. I reconciled to be safe, nothing was found, and I went to restart the long submit.
  • When I tried to submit, I was warned there wasn't adequate space on the drive anymore. The drive was double the necessary space when I made it, so I used EC2's Session Manager to connect and look at the disc space. Sure enough, there was a huge chunk of storage being consumed, as if many of the files I was submitting had actually uploaded and were now taking up space.
  • But p4 doesn't see this and reconciling isn't helping.

My skill level: While I've worked in games for years and am familiar with using p4 for a project, most of my experience is in the design/art side of things, with engineering being new to me. And even then, most of my engineering experience is in game logic, not server infrastructure. I had to follow tutorials to get set up in AWS.

My thoughts from here:

  1. Using "p4 sizes -s //depot/directory/...", I'm told there are 0 files and 0 bytes. But again, if I check on EC2 itself using Session Manager, I can see well over 100gb in the depot that were not there prior to the submit effort.
  2. If I can't figure out a better approach, I may have to just grab the first snapshot that was taken after setup, before the attempt, and figure out how to restore the depot to that state. But the tutorials and info I've seen about how to do this seems to be more about completely replacing the instance/volume with the snapshot, rather than resetting to it, and that makes me nervous about breaking something from the Helix Core template I got and breaking how p4 is talking to the server. Again, this is all very new to me and there's so many common and shared terms that googling is only getting me so far.
1

There are 1 best solutions below

0
Jase On

As Samwise mentioned, p4 storage is the safest way to fix that.

A couple extra pieces of info that might help:

  1. On the AWS template, the depot files are stored in /p4/1/depots/DEPOTNAME so you can go in there to check on those orphaned files.
  2. p4 storage -d by default only deletes orphaned files that were scanned at least 24 hours ago (86400 seconds) but this can be overridden (see below)

Check th efp4 storage options here: https://www.perforce.com/manuals/cmdref/Content/CmdRef/p4_storage.html#Options

Try these steps and see if it helps:

  1. Start the scan: p4 storage -l start //DEPOTNAME/...
  2. Check the status until it's done: p4 storage -l status //DEPOTNAME/...
  3. Run -d with the -D flag to change 24-hour limit: p4 storage -d -D 60 -y //DEPOTNAME/...
    -D sets the time limit since scanning to 60 seconds. You could use a different number of seconds, if needed.
    This will display the files to delete but won't delete until you run again with -y.
  4. Finally, run with -y: p4 storage -d -D 60 -y //DEPOTNAME/...

You should see an output with all the files being deleted and a message confirming that they were deleted.