Legacy
rating: 0+x

Technical Researcher Mason looked to the corner of his screen, reflexively checking the notification. Great, 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 since they forgot to.

- Technical Researcher Rosen

▸ Show quoted post

Mason sighed. This week had been positively awful. For whatever reason all the tickets had been going to him, and he really needed to finish adding media caching to ElevenNet. Pulling up the SCP file, he hoped it would be as easy as Rosen suggested.

exclusion-zone.jpeg

Aerial view of the SCP-4168 exclusion zone.


Item #: SCP-4168

Object Class: Euclid

Special Containment Procedures: Stationary Task Force Gamma-47 ("Birthday Clowns") is to patrol the SCP-4168 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-2718-1 instances are to be gathered, catalogued, and incinerated.

Successfully reproduced. Mason cringed as he noticed the hard-coded SCP number in the containment procedures. People sucked at reading instructions. Analytics loved shuffling files around: most things filed recently probably weren't going to stay there for long. This looked like a simple case of the attachment having an incorrect filename.

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

So hopeless. At least all he needed to do was a rename and item number fix.

cmason14@galba /mnt/scipnet/scp-4168$ mv {scp-2718-,}exclusion-zone.jpeg
cmason14@galba /mnt/scipnet/scp-4168$ vim article.wd
cmason14@galba /mnt/scipnet/scp-4168$ scpctl update-meta

exclusion-zone.jpeg

Aerial view of the SCP-4168 exclusion zone.


Item #: SCP-4168

Object Class: Euclid

Special Containment Procedures: Stationary Task Force Gamma-47 ("Birthday Clowns") is to patrol the SCP-4168 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-4168-1 instances are to be gathered, catalogued, and incinerated.

Uh.

Mason refreshed the file. And a second time. Hard reload. Cleared 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 for them, but he had already manually updated the metadata. And it couldn't be some file server buffering, this was directly onto a scipnet mount. Sure enough, he checked the sync status and saw it was up-to-date. The image was present and had the correct name, it just wasn't displaying.

When was this file created anyways?

cmason14@galba /mnt/scipnet/scp-4168$ cat metadata.json
WARN: Invalid access at 0x7f9160798b40, flagging file as potential infohazard

What? That's not JSON. The article was rendering fine, and Mason had literally just updated this file, how was it some logging message? This couldn't be what happened when an anomaly modified its own file, right?

Yeah, it wasn't. Scanning through the RAISA infohazard protocols, it was noted that metadata.json should always be valid JSON. In this case, the flags list should simply have "potentialInfohazard" in it. And just looking at SCP-4168, it did not strike Mason as being the type to cause database issues. Speaking of which, why was everything else about the entry working? If the metadata was corrupted, viewing the file at all should fail.

An hour had passed. Apparently metadata.json wasn't where information was actually stored, it was just a nice JSON view for local applications. All the actual information was stored in separate, encrypted sectors within SCPDB, and scipnet just gave us the pretty version to make our lives easier. Unfortunately, Mason couldn't just query the article directly to try and figure out what was wrong, as that would require direct access to the database. 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.

"4168?" 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.

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
scp-071
scp-2070
scp-3082
scp-4168
scp-5985
scp-6309
scp-7024
scp-8155

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 4168 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 4168 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.

"Hmm?"

"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?"