rating: 0+x

Technical Researcher Mason looked to the corner of his screen, reflexively checking the notification. It was yet another email from Rosen.

From: David Rosen [drosen02]
To: Craig Mason [cmason14]
Sent: 2019/02/04 14:07
Subject: Fwd: Scp not displaying picture

Hey I thought this issue would be perfect for you, shouldn't take too long. Created ticket #1D7QLJT3.

- Technical Researcher Rosen

▸ Show quoted post

Mason sighed. This week had been positively awful. For whatever reason all the tickets seemed to be going to him, and his supervisor was starting to get on his case about the lack of progress on ElevenNet's media caching. Begrudgingly, he pulled up the SCP file.


Aerial view of the SCP-4863 exclusion zone.

Item #: SCP-4863

Object Class: Euclid

Special Containment Procedures: Stationary Task Force Gamma-47 ("Birthday Clowns") is to patrol the SCP-4863 exclusion zone and turn away all civilians, administering amnestics to those with knowledge of the anomaly. Should a BALLOON event occur, agents within the USGS are to falsify earthquake data. Following the incident, all SCP-7220-1 instances are to be gathered, catalogued, and incinerated.

Successfully reproduced. Mason cringed as he noticed the hard-coded number in the containment procedures instead of using the correct [[item]] tag. Evidently, some person over at Analytics had decided to reorder the files, and now some of the references were inconsistent.

This thankfully looked like a simple case of the attachment having an incorrect filename. All that was left was to quickly fix the item number and image and he could close this damn ticket.

cmason14@galba /mnt/scipnet/scp-4863$ ls -l
.rw-r----- scp-4863 18 Jan 12:04 article.ftml
.rw-r----- scp-4863 16 Jan 08:39 exploration-log.ftml
.rw-r----- scp-4863 12 Dec 15:26 geological-survey.ftml
.r--r----- scp-4863 04 Jan 12:04 metadata.json
.rw-r----- scp-4863 30 Dec 08:11 instances.db
.rw-r----- scp-4863 28 Jan 09:35 scp-7220-exclusion-zone.jpeg
.rw-r----- scp-4863 29 Dec 19:52 task-force-charter.pdf

Of course. The idiot put the item number in the filename too.

cmason14@galba /mnt/scipnet/scp-4863$ mv {scp-7220-,}exclusion-zone.jpeg
cmason14@galba /mnt/scipnet/scp-4863$ vim article.ftml
cmason14@galba /mnt/scipnet/scp-4863$ scpctl update-meta


Aerial view of the SCP-4863 exclusion zone.

Item #: SCP-4863

Object Class: Euclid

Special Containment Procedures: Stationary Task Force Gamma-47 ("Birthday Clowns") is to patrol the SCP-4863 exclusion zone and turn away all civilians, administering amnestics to those with knowledge of the anomaly. Should a BALLOON incident occur, earthquake data is to be falsified and sent to USGS. Following the incident, all SCP-4863-1 instances are to be gathered, catalogued, and incinerated.


Mason refreshed the file. And a second time. Hard reload. Deleted scpctl's local cache. Still nothing.

Pulling up the debugger, he saw the error was "EATTACH", or "attachment not found". This wouldn't happen to regular users, as they used the fancy editor that managed attachments and fields for them, but he had already manually updated the metadata. Was it file server buffering? No, he was directly on a scipnet mount. Sure enough, the sync status reported all the files as being up-to-date. The image was present, it had the correct name, it just wasn't displaying.

When was this file created anyways?

cmason14@galba /mnt/scipnet/scp-4863$ jq -r .created_at metadata.json
parse error: Invalid numeric literal at line 1, column 5
cmason14@galba /mnt/scipnet/scp-4863$ cat metadata.json
WARN: Invalid access at 0x7f9160798b40, flagging file as potential infohazard

What? Somehow the JSON file was all messed up. Maybe this was a case of an anomaly modifying its own file?

Apparently not. Thumbing through the RAISA infohazard protocols, it was noted that metadata.json should always be valid JSON. In this case, the flags list should have "potentialInfohazard" or "potentialOntology" appended to it. Just looking at SCP-4863, the anomaly did not strike Mason as the type to cause these sorts of things.

Speaking of this, why was the file working at all? If the metadata was corrupted, then there should be a lot bigger issues than a missing image. A lot of small things just weren't quite adding up.

Twenty minutes had passed. Apparently metadata.json wasn't the actual location of the information, but was merely a convenient way to interact with it. The real data was maintained in separate, encrypted sectors within SCPDB, which was automatically collated to make life easier.

Unfortunately, it was currently broken. Or at least it seemed that way. Normally you would look at the relevant bits of data and try to see where things went wrong, but this was with the database and scipnet. Nobody has raw read access to the main database: it's a huge security risk. Shrugging, Mason opted for a different approach.

jcooke02@blue /mnt/scipnet$ for item in scp-{002..9999}; do
jcooke02@blue /mnt/scipnet> . jq . "$item/metadata.json" || echo "$item"
jcooke02@blue /mnt/scipnet> done

Apparently this wasn't the only file to be affected by the corrupted metadata issue.


. He decided it was time to bring in the big leagues: Database Reliability Engineer Jennifer Cooke.

"You already checked your local connection is healthy?"

Mason nodded. There was a pause while Cooke typed away at her laptop.

"4863?" More typing.

"Yeah, I'm getting it too. Looks like a different address though."

More typing.

Mason cleared his throat. "Uh, do you think it's data corruption?"

"Well, let's first see if it's just this file or there are others affected."

Cooke pulled up the status board. Only a handful of slots were red and all had attached tickets, a cursory inspection of which seemed to be unrelated. Opening up a shell, she whipped up a quick script to check the other metadata files.


In a moment of shared silence, both researchers furrowed their eyebrows.

todo rewrite: After some further fiddling, a few things had become clear. All the typical utilities were mostly working as expected even though their metadata.json files were busted. SCPDB itself wasn't logging anything unusual for the problematic slots. And most unusually, only 4863 and 7024 had broken attachments. It seemed the problem layer deeper within the stack.

Further poking and prodding commenced. It seemed that the typical utilities were working as expected, and SCPDB's visible logs weren't showing anything unusual for the problematic slots. Addenda and images all seemed fine save for 4863 and 7024, which simply reported an unhelpful EATTACH.

Cooke frowned. "I was hoping we wouldn't have to, but I think we should check Scarecrow."

"I'm sorry?"

"It's the debugger for the scipnet protocol. Basically a dummy app that mimics calls and shows you the results."

"Ah. Is it difficult to use?" Mason asked.

The application finished opening as he asked that. It looked functional, but had a distinctly late 90's UI aesthetic. And was written in ASP.NET.

After several minutes, a quiet routine had emerged. Cooke would try a scipnet call, it would succeed, but give weird data on occasion, which would disappear after a few attempts. Mason would search through the RAISA documentation and they would both scratch their heads wondering whether it was intended behavior. And then again.

Mason leaned back in his chair and shrugged. "I guess it's just the meta call that's failing. Not sure why it doesn't validate the JSON."

"I've never heard of issues, I guess it just always worked," she mused. "Wait!" Her tennis shoes slapped on the floor suddenly. "The JSON-based metadata was added recently, maybe some uncommon piece of data's not getting serialized properly. That would explain the weird memory shit."

"Wait, it was? What did we use before?" Mason asked.

"Heh, it was this ancient Foundation thing called CDF, compressed data format. I believe this is the origin of all our addenda being separate files, it tried to "save space" by only sending these weird reference numbers that you could independently fetch, as well as some weird data squashing stuff. The spec on the thing is a hundred-something pages." Cooke air-quoted aggressively for emphasis.

"Oh boy. I guess we need to debug the scipnet server then."

"It looks like it. I don't think anybody has updated the protocol for years. We can't remote in from here for security reasons. Follow me back to the lab," Cooke instructed. Obediently, Mason gathered his things.

Walking through Site-11, they came to a nondescript metal door near a security booth. After some paperwork for Mason, the pair were admitted into the room. A few rows of server racks were present, each with a small terminal emblazoned with a modified Foundation logo featuring a disk pack at its center. Cooke lifted up a flap on the desk and set her laptop on it.

She swiped her keycard and logged in.

jcooke02@omicron ~$

----- todo ------

"Wait," Mason gazed at the computer screen.


"This weird timekeeping scheme, if the cycle field is more than… yeah. Scipnet has got to be at least 200 years old." Mason stroked his chin.

"That… what? We didn't use silicon for computers until about the sixties. It's probably for temporal anomalies or something," Cooke replied.

"I don't know, the clock looks solidly monotonic. Just how old is this thing?"

they find that the time field is wack and that's causing the images to not display
they wonder why it's so offset
they shrug and file a possible anomaly report

Doctor Charles Gears frowned as he noticed the potential anomaly report in his queue. Lately there had been a number of them, corresponding to old containment breaches or improperly-purged records. He glanced over it, pausing to enter his credentials, then promptly archiving the file after reading its contents.

Report #: PAR-213038

Tags: Electronic, Temporal, Internal Origin

Filed by: Craig Mason [cmason14], Jennifer Cookie [jcooke02]


While investigating #1D7QLJT3, we discovered an unusual but mundane software bug in some legacy code surrounding the infohazard-resistant date storage. While the issue has been fixed, we noted several SCP files which have date values offset significantly into the past.

Attempting to find the root cause of this issue led us to discover logs from a few weeks ago in the Site-11 mainframe. However, we lack clearance to see all the entries; by looking at surrounding context we hypothesize that a previously-undetected temporal anomaly or CK-class scenario occurred, from which Foundation servers attempted to automatically recover.

The relevant log entries have been attached below:


📎 ticket-1d7qljt3.ftml
📎 unusual-time-shifts.csv
📎 scpdb-state-dump-2019-02-04.bin

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License