Why does my computer break so much?
As I work on more coding projects, I use more tools, which come with limitations, so I have to restructure my folder hierarchies. Sometimes, these necessary changes break things.
Today I wanted make a QR code for some links, but did not want to use one of the many websites that already exist to do it, because they all want you to sign up, or they don’t let you copy the image directly from the web page (they make you download the PNG or SVG file).
QR is a standard algorithm. So, I thought, since search engines produce nothing but links to these websites, someone on GitHub has to have made an open source library for QR code generation. I found a library written in a systems language, which I could use later to make a neat desktop app.
First step is to download the code.
While cloning the repository from GitHub with git clone, I was met with an error:
PS S:\Google-Drive\Programming\Projects> git clone git@github.com:nayuki/QR-Code-generator.git
Cloning into 'QR-Code-generator'...
no such identity: S:\\Google Drive\\Programming\\Keys\\SSH\\ryan.johnson.code@gmail.com ED25519 2023-04-23\\id_ed25519: No such file or directory
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.Confused and irritated, I started debugging. The last time I’d cloned, everything had worked perfectly. Why was it failing now? I thought maybe it was the SSH URI that was the issue. I could just use HTTPS but was pretty sure I’d used SSH before. What happened to my SSH key file? Recently I’d had my primary disk get corrupted twice in one week, and chkdsk kept failing at boot, so I had to run chkdsk from a second copy of Windows, so I’ve been really suspicious of read errors lately. I thought maybe my SSH file had been affected.
I went ahead and started looking at the man pages to confirm I could use SSH URIs with their command. I tried a few different possible help commands and git clone --help ended up working. As a side note, the git clone help file opens up in a web browser, which is kind of neat. That’s much better than the terminal for readability and searchability.
Anyway, according to the doc, the SSH URI should work.
A Simple Rename, a Broken Workflow
The problem was painfully simple: my .ssh folder was in my Google Drive folder tree, but I had renamed my Google Drive folder last week to “Google-Drive” to accommodate the C and C++ compiler toolchain that didn’t tolerate spaces in folder names, so the system couldn’t locate it anymore. Something as trivial as renaming a folder had confused the system. Not only that, the connection between the two was not immediately apparent, because more likely culprits dominated my attention.
I didn’t know how the SSH tool knew where to look for the keys, so I looked that up: It stores the location in a config file which I totally don’t remember ever touching before. I opened the config file and changed the path, and went back to cloning my project.
Not an Uncommon Problem
While this problem wasn’t all that difficult to figure out, this kind of problem could result in much more difficult subtle bugs, particularly when the time between breaking the path and discovering the problem. This special kind of annoying problem is all because the hierarchical filesystem can’t adapt to the change.
It wasn’t the first time this had happened. Over the years, I’ve seen similar issues crop up:
- Scripts breaking because file paths changed.
- Backup systems failing because folders were moved.
- Applications losing references to configuration files.
The problem isn’t the tools. It’s the structure we rely on. This problem is one more example of why hierarchical filesystems should be abandoned.
The Irony
What’s ironic about this situation is that the very tool I was using—Git—doesn’t rely on a rigid folder hierarchy internally. Git uses a content-addressable storage system, where files are identified by their content, not their location. This allows Git to track changes no matter how you move or rename files in the repository.
Meanwhile, the operating system forces us to cling to a fragile hierarchy. Rename or move one element, and everything tied to it can break. It feels archaic when compared to the flexibility we’ve built into version control systems, cloud storage platforms, and even modern photo libraries.
Rethinking Filesystems: What Could Be Better?
This experience reinforced a key point: hierarchical filesystems are a relic of the past. They are 55 YEARS OLD. Multics was the first operating system to offer a hierarchical filesystem, and its first release was in 1969. They’re static, inflexible, and break easily under the demands of modern workflows. So, what could replace them?
- Content-Addressable Storage
Imagine if files were referenced by their unique content or metadata instead of their location. Moving a file wouldn’t matter, because the system would know exactly what it is, regardless of where it “lives.” This term, while newer, is the same as a GUID (Globally-Unique Identifier), which is a core feature of the file-system I want to create. - Tag-Based Organization
Instead of a rigid folder tree, files could be tagged with multiple attributes—project names, dates, file types, and more. This way, a single file could “exist” in multiple contexts without duplicating it. This kind of organization is already used in Gmail and most photography library management suites. - Smart Search and Context Awareness
Why navigate deeply nested folders when you could type a query like “SSH key for GitHub” and immediately find the right file? Smarter search functionality combined with rich metadata would eliminate the need to micromanage locations. This particular flavor of workflow is compatible with today’s emphasis on AI large language models and vector databases.
Moving Forward
Renaming that folder was a small mistake, but it revealed a big problem. Hierarchical filesystems are no longer fit for the complexity of our digital lives. The irony is that many of the tools we rely on, like Git or cloud platforms, have already moved beyond this model.
Maybe it’s time our filesystems caught up. By embracing smarter, more flexible approaches—content addressing, metadata, and search-driven systems—we can spend less time untangling file paths and more time focusing on the work that matters.
So, next time a folder rename breaks your workflow, take a moment to think: Is it the mistake, or the system that allowed it to happen? Are you programming the computer, or is it programming you?
Leave a Smart Comment