February 20, 2020 at 9:53 AM by Dr. Drang
I’ve written in the past about how I’ve had to use tags to work around a misfeature of Files: that it doesn’t display full file names, including the extensions. Today I learned that there’s a bug in that misfeature.
I was working from my iPad on some files that were stored in iCloud Drive. Here’s Files showing the contents of the folder I was working in:
The file with the blue dot has a
.tex extension. The extension isn’t shown, which is the normal (and frustrating) way Files behaves. But the file with the green dot has a
.py extension and its extension is shown. What’s going on?
My first concern was that the green file somehow had two extensions—that its full name was
sampling.py.py—so I opened a Terminal in Textastic,1 navigated to the appropriate iCloud folder, and ran
ls to see the real, full names of both files.
As you can see, there was no double extension.2 The problem wasn’t that I had somehow misnamed the Python file, it was that Files has a bug in the name display. It happens to be a bug I approve of, and one that I wish were consistent across all file types at all times, but it’s a bug nonetheless.
It says something about the state of software quality at Apple that it can’t even get its design errors right.
Normally, I’d do this in Prompt, but I was in the middle of editing one of the files in Textastic when I noticed the extension anomaly in Files, so it was quicker to start a terminal session there. I really like Textastic. ↩
If you’re looking at the path in the terminal session and wondering why an iCloud folder isn’t in
~/Library/Mobile Documents/com~apple~CloudDocs, its because I made a symbolic link to the
projectsfolder in iCloud from a
projectsdirectory in my home directory. Saves time when using the
cdcommand, whether I’m working directly on my Mac or remotely through terminal emulation. ↩