Archive for the ‘nit pick’ Category

Filename Conflicts On Download

Thursday, March 4th, 2010

I was very satisfied when Apple revisited how the Finder handled some of its file-naming architecture. Some behaviors were bugs and absolutely had to be fixed. For example, prior to Leopard there existed a mixed behavior when renaming files under different view modes (Column View, Icon View, Detail View, etc.).

Finder's toolbar buttons for the different View Modes.

Normally if you start changing the name of a file and change your mind you could hit the Escape key, and the name would be restored to what you started with. However, under the Column View, hitting Escape was equivalent to hitting Return, and whatever text you currently had would be accepted. Very annoying! Obviously the first behavior is more intuitive, and it is inarguable that the renaming file behavior should be consistent throughout all View Modes.

The Good

Finder's intelligent filename selection which excludes the extension when renaming.The feature I most liked, however, was that if the extension of the file is visible and you started renaming it, the entire filename except for the extension was selected. This change made renaming much quicker and easier because not only did you no longer have to remember the extension, but less typing was required (on average four characters: period + three letter extension). At first these four extra characters might not seem like too much work, but if you rename a list of files, you would drastically notice the difference.

The Bad

There is at least one more thing that I see that needs to be changed. When Safari downloads a file and another file already exists with the same name, it begins appending sequential numbers (preceded by a dash) to the end of the filename in order to distinguish them (“-1”, “-2”, “-3”, etc.).

Two icons showing the intended behavior of Safari's renaming algorithm when downloading files with the same name.

But is the added suffix really appended to the end of the filename? Turns out it isn’t and I consider it a major bug. Say what you will, but I don’t see it as simply a behavior that isn’t necessarily right or wrong. I think it’s obvious what the intention is (refer to the screenshot above) and the screenshot below shows an example when the intention doesn’t carry through. From my observations, the Finder inserts the “suffix” immediately before the first period it encounters while searching from beginning to end of the filename. It should be inserted before the last period.

Two icons showing the malfunction in Safari's renaming algorithm.

The Solution

It would be very easy to iterate from back to front of the filename (my Page Capture widget does). And it happens to be more efficient since extensions are typically shorter than the actual filename. Hopefully someone over at Apple reads this post and fixes the problem. While they’re on it, they might as well fix the other problem I’ve mentioned with the TextEdit Autosave algorithm.

Gross iPhone OS Update Typography

Monday, November 9th, 2009

Check out the first line of the update message in the screen shot that I took on my iPod Touch below. The mistake between ‘O’ and ‘0’ is too apparent to not write about… not to mention typographically gross!

Screenshot Someone’s finger must have slipped from the ‘O’ to the ‘0’ — bad form!

Apple’s TextEdit App. Can Erase Your Files

Tuesday, May 12th, 2009

Icon of the TextEdit Application.Apple’s TextEdit application has a massive design flaw that could potentially erase other files on your computer. Weird, right? Ironically, it’s TextEdit’s safeguard against loss of data that is the culprit of the defect. And the corruption of files isn’t a randomly occurring glitch either — it is caused by a shortcoming of the algorithm used in the Autosave feature.

The Autosave Flaw

When editing a document in TextEdit, a copy of your work is automatically saved every 30 seconds to the hard drive*. This behavior is common in software as it provides a convenient means to recover some of your work should the application unexpectedly quit or crash.

Unfortunately, the means by which TextEdit saves a copy of your work is awfully rudimentary. It simply writes your data to a regular file and gives it the same name as your TextEdit document but with “ (Autosaved)” appended as a suffix (without an extension). And since no verification is performed to see if a file with that particular name already exists, it will overwrite anything that gets in its way with no confirmation or warning!


To better illustrate this flaw, take the following scenario. Suppose, for whatever reason, that I have a file named Craziness (Autosaved) and I create a text document called Craziness.txt in the same directory. In the screenshot below Craziness (Autosaved) is an image file (with the extension removed in order to illustrate my point):

Screenshot of my 2 original files.

When I start editing my Craziness.txt file in TextEdit, the application autosaves my work (as it should), but since my image document has the same name as what TextEdit would call its autosaved file, my image file is overwritten:

Screenshot of TextEdit's autosaved file.

When I’m done editing my Craziness.txt document, TextEdit removes the autosaved copy (as one would expect). However, now my original image file is gone with no real way to recover it (since it’s not moved to the Trash but actually overwritten):

Screenshot showing loss of data caused by TextEdit.


Accounting for this file naming issue is so programmatically simple that it’s astounding the defect even exists. The simplest improvement would be to prefix the filename with a period (as in .Craziness (Autosaved)) in order to hide it from the Finder since the chances of having a naming conflict with a hidden file are greatly reduced.

But hiding the file from the user still allows for potential name collisions and as Mac OS X’s default text editor, TextEdit’s naming convention should be even more robust. To start, TextEdit could include either a timestamp or a sequence of random numbers to help make its autosaved filename unique. Most importantly, however, should be to verify if a file would be overwritten and if so, generate a different random number or append an incremental counter. Heck, even my Page Capture widget won’t overwrite files since it uses the same naming convention as Apple’s screencapturing application (File 1, File 2, File 3, etc.)

The Rant

One might argue that the possibility of having a file end with “ (Autosaved)” and not have an extension is pretty slim. So what? My argument is that the possibility of an application deleting other files blindly is a completely unacceptable use case scenario, no matter how rarely it may occur. I think it is more reasonable to expect that a corporation as large as Apple Inc. would produce software that doesn’t delete unrelated files from my hard drive without my knowledge. Especially since OS X is — as Apple claims — the “most advanced operating system in the world.”

*30 seconds is the default. The time interval is configurable and the user is allowed to disable the Autosave feature entirely.