Betalogue

There are new problems in Spotlight in Mac OS X 10.5 that are obviously related to changes made by Apple to the way Spotlight search results are presented. And I am afraid there are situations where these problems can lead to destructive consequences.

I cannot provide 100%-reproducible scenarios, which makes the bugs particularly hard to track down. I submitted all the information I had to Apple a while ago, but obviously without 100%-reproducible scenarios, I don’t expect them to do much about it, which is rather unfortunate because, as far as I can tell, these are very real problems, some of them actually quite common, at least on my machine. Here is what I can say about these problems.

Typically, I open a Finder window and start a search by putting a phrase or keywords in the search field in the toolbar. The Finder generates a list of matching files. As indicated in a previous post, the options for viewing these search results are limited. You can have either an icon view (useless when the number of items gets high) or a list view or a cover flow view. In both the list view and the cover flow view, there are only three columns: “Name,” “Kind,” and “Last Opened.”

These column view options cannot be changed. All you do is change the column widths (which, again typically, are not appropriate by default and need to be changed again and again, because the Finder does not keep track of user changes in that respect) or click on a column header to sort the results (in ascending or descending order) based on that column.

These, however, are “merely” design flaws. Now on to the bugs…

First of all, there is a problem when you attempt to open files in the list of search results by double-clicking on them. The problem is that, quite often, the simple fact of double-clicking on a file causes it to disappear from the list of search results altogether.

It’s not immediately noticeable if you have a smaller screen and the foreground window (i.e. the document window of the file you’ve just opened) obstructs your view of the Finder window with the list of search results in the background.

And it does not happen all the time. Indeed, I cannot reproduce it reliably if I create a brand new folder and add a number of new files to it and do a search focused on that new folder that I know will return results. But I definitely experience this disappearing act quite often when conducting system-wide searches that return long lists of results from various corners of my various hard drives, with files that are sometimes several years old (yet still relevant, of course). Unfortunately, I cannot send my entire collection of hard drives as an attachment with a bug report to Apple…

Obviously, it does not make any sense that the file should disappear from the list of search results as soon as you open it. The simple act of opening it certainly does not change anything to its contents, and therefore the open file continues to match the search criteria of the Spotlight search request and should remain in the list of search results.

What I suspect, however, is that what causes the file to disappear has to do with the fact that the simple act of opening the file changes its Last Opened date. Since the “Last Opened” column is one of the columns in the list of search results when viewed as a list (or with the cover flow view mode), then obviously the display of the file in question in that list is going to be affected. The Last Opened date of the file should change (to right now), and, if the list is sorted by Last Opened date, then the position of the file in the list should change. (This is another reason why using this “Last Opened” column in the list of search results is a bad idea. A “Modified Date” column would be much preferable, or should at least be an option.)

But that’s not always what happens. Instead of changing, sometimes the file disappears from the list altogether! And once it has disappeared, the only way to make it reappear is to cancel the search altogether and start all over again by re-entering the keywords in the search field in the toolbar.

This disappearing act occurs on my machine on a regular basis—even though, as I said, I cannot reproduce it reliably with a brand new folder containing brand new files, which makes it hard to report to Apple as a bug and to get them to pay attention to it. But it’s definitely not just my imagination! This bug is real. I’ve seen it happen, again and again.

That’s not the worst of it, though. What I have also noticed is that, sometimes, after I’ve worked with various files by accessing them through a Finder window with a list of Spotlight search results, opening some of them, closing them, opening and editing others, etc.—then all of a sudden one of the files involved has its very file name itself seemingly randomly changed by Mac OS X to the name of another file recently accessed.

The first time this happened to me, I thought that I had just accidentally changed a file’s name by mistake through a misguided copy-and-paste operation. Sometimes I work too fast, and accidents do happen. But then it happened again. And again. Since I first started using Mac OS X 10.5 on my production machine, back in November 2007, it has happened to me at least half a dozen times. Sometimes it’s a Pages document that takes on the name of a PDF file. Sometimes it’s a PDF file that takes on the name of an RTF file. Sometimes it’s even a folder that takes on the name of a Pages file! I might be occasionally clumsy, but there is no way that this behaviour can be explained by my actions, especially after several years of using Mac OS X without any such problems.

And the name change is complete, i.e. it includes the file extension as well, which causes Mac OS X to become completely confused about what the file actually is. The time I had a folder whose name was changed to the name of a Pages document, I noticed the problem when I tried another search for a key phrase and I didn’t get the expected results, even though I knew I had files that contained that phrase. It turned out that the folder that contained the files that contained that phrase had had its name changed to the name of another Pages document that I had recently opened!

Because of this, Mac OS X no longer treated the folder as a folder, and the files it contained were no longer part of the Spotlight index for the volume. In fact, I thought I had lost the files altogether, until I saw that, by applying the “Show Package Contents” command to the pseudo-Pages document, I could view its contents and see my missing files in there! (I also had a recent backup, from which I could also restore them.)

What prompted me to write this post today what that the same problem occurred again this afternoon, this time with Mac OS X renaming an RTF file that I had recently opened using the name of a PDF file that I had also recently opened. And in fact, this time, in the process of randomly renaming the file, the Finder (which was in the background at the time), requested my attention with an alert complaining that another file with the same name already existed! I clicked on the “OK” button in that dialog (the only option available), and the Finder returned me to the Finder window with the list of search results, but I had no way to tell which file had been affected by the bug this time!

Fortunately, since this was very fresh in my memory, I actually remembered the contents of that list of results, and was quickly able to identify the file that had been affected. In fact, even though I had responded to the alert about the name conflict by clicking on “OK,” which normally causes the Finder to revert to the previous file name, the random file name change had taken place just the same! Presumably this was because the alert itself was erroneous, since the two files didn’t live in the same folder and were only in the same list because it was a list of search results from various locations… In any case, the RTF file now had the name of another PDF file that I had opened recently. And of course, when I tried to open that pseudo-PDF file, Preview complained that it wasn’t a properly formed PDF file. No kidding!

This particular bug is actually quite scary, because it is in fact destructive. I can live with the bug that causes files to disappear from the list of results, because it’s a bug that does not affect the files themselves, just their display in the results window. But this is something else altogether! Mac OS X seems to randomly rename files behind the user’s back, and there’s no indication that this renaming has taken place, unless you are lucky enough to get an erroneous alert message about conflicting file names! (This was the first time I got this alert at the time the bug occurred.)

I said above that the bug has occurred on my machine at least half a dozen times since November 2007—but these are the occurrences that I have actually noticed, indirectly, by browsing my files and noticing weird issues with files missing or not being where they are supposed to be! (Thank God I am fairly well organized and am actually able to notice these things…) Who knows how many files and folders Mac OS X 10.5 has renamed behind my back without my noticing them?

This really worries me quite a lot, because there is usually no way to tell when the bug occurs. I only notice that it has occurred indirectly, after the fact, sometimes days later—if I notice it at all.

Again, I am unable to reproduce it reliably, so it is particularly frustrating and worrying, because it means that I might have to endure it for months or even years.

What I strongly suspect, however, is that this random renaming bug is related to another obvious (100% reproducible) flaw in Spotlight search results window, which is the fact that file and folder names in a search results window are actually editable!

This does not make any sense to me. It should not be possible to edit file names directly in a search results window. A search results window is not a regular Finder window. It’s a window that lists search results and allows you to browse these results, sort them, etc. But if you want to rename one of the actual files (or folders), you should be forced to open the item’s enclosing folder in another Finder window and rename the item there. It should not be possible to rename the item directly in the list of search results. (It was not possible in the previous incarnation of Spotlight, as far as I can remember.)

In fact, I know for certain that someone at Apple agrees with me here, because I reported this as a bug in a early build of Leopard during the AppleSeed testing period, and the bug was fixed in a later build, and I got an e-mail from Apple asking me to confirm that the bug was fixed, which it was. Unfortunately, the bug reappeared later on in the development process, and I didn’t catch it again until the product was released, and obviously no one else did—or someone at Apple changed their mind and decided that this was a good idea after all, which I strongly disagree with.

I strongly suspect that the fact that item names are editable in a Spotlight search results window has something to do with the random renaming bug, because the list view in general in Mac OS X has a long history of being buggy and handling editable-name mode in a non-standard and unpredictable fashion.

In fact, I have seen it happen with my own eyes: I would switch from a Finder window with a list of search results to another application and then back and then sometimes when attempting to open an item in the list of search results I would accidentally cause the item’s name to become editable—sometimes at the same time as Mac OS X was opening the item and relegating the search results window to the background, because my double-click was interpreted in two different ways by Mac OS X at the same time.

Unfortunately, again, I am unable to provide a more accurate and more reproducible scenario for these bugs. But I am 100% certain that there is indeed something very wrong with search results windows in Leopard’s Finder, and that there are bugs that can indeed have some very destructive consequences, such as changing an entire folder of files to a pseudo-Pages document and causing all these files to become lost!

I have reported all this to Apple, albeit without the 100% reproducible scenario that they would need, and they have responded to the bug report about random renaming a few times by asking me whether it was fixed in newer builds of Mac OS X 10.5.1 and Mac OS X 10.5.2—probably hoping that something else that they had fixed in the newer version might have indirectly fixed that problem too.

But unfortunately it has not been fixed. It’s still there, and I honestly have no idea how many files on my hard drives might already have been affected without my noticing the fatal file name changes. It worries me quite a bit, and I am writing this blog post also with hope that other people might have noticed the problem too and might have further information about how to reproduce it reliably, so that we can submit better bug reports to Apple and get it fixed as soon as possible!

This entry was posted by Pierre Igot on Thursday, February 28th, 2008 at 6:42 pm and is filed under Macintosh. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.