Camino and Downloads folder: Untitled folder name fails to stay editable while download is in progress in list view

Posted by Pierre Igot in: Macintosh
January 3rd, 2008 • 2:19 pm

Some bugs are more obscure than others.

The title of this blog post is a bit of a mouthful, but it describes the exact circumstances in which this particular problem occurs.

You need to have your “Downloads” folder open in a Finder window in list view.

You also need to use the Camino web browser. (I cannot reproduce the problem with Safari.)

And you need to have a large download currently in progress in Camino, which means that there is a temporary file in the “Downloads” folder that is constantly increasing in size. (Camino uses the file name of the actual file being downloaded, with the “.part” file extension appended to it. Curiously, Camino also creates another item in the list with the file name of the actual file being downloaded, without the “.part” file extension, but that other item stays at zero KB until the download is complete, at which time the temporary “.part” file disappears and the other item becomes the final, complete download.)

It does not matter whether the folder in list view is sorted by file name or by date modified.

Then, if, while the large download is still in progress, you try to create a new folder inside the “Downloads” folder, either by selecting the “New Folder” menu command or by pressing shift-command-N, Mac OS X does what is expected, i.e. it creates a new folder with the default name “untitled folder,” it selects that folder, and it makes its name editable, so that you can immediately type a new folder name.

The trouble is that there is no time to type a name, because after a fraction of a second the Finder exists the editable-file-name mode and switches back to the regular selection mode, where the folder is simply selected, but its name is no longer editable.

And if you start typing something now, of course, instead of actually entering the folder name to replace “untitled folder,” the Finder thinks you want to select a file or folder in the list by its first letter, so it jumps away from the untitled folder and selects another file or folder in the list, based on the letters you’ve just typed.

I can only reproduce this reliably when a large download is in progress in Camino. If a large download is in progress in Safari, then there are no problems. The “untitled folder” name remains editable.

I also cannot reproduce the problem in column view mode or in icon view mode. It only occurs if the “Downloads” folder is open in a Finder window in list view.

My guess is that something in the downloading process in Camino causes the Finder to “refresh” its file list all the time, and this refreshing process causes the Finder to exit the editable-file-name mode. But this only occurs when creating a new untitled folder. If I try to edit an existing file name in that same list view, there are no problems. I suspect that this is because the newly created untitled folder has a modified date that is even more recent than the temporary file with the “.part” extension. The temporary file obviously has a modified date that changes all the time (because it is modified all the time while the download is still in progress), but the newly created untitled folder is always even more recent.

Strangely, though, the problem occurs even when the list view is sorted by name rather than by date modified. When the items are sorted by name, you would think that the change in the modified date would have no impact on the list, since it does not affect the ranking of the items in the list. But the problem still occurs, whenever you create a brand new untitled folder.

Of course, this is a very minor problem. What I find interesting about it is that it is obviously is a manifestation of some kind of underlying, invisible mechanism involved in keeping the list of the folder’s contents in list view in sync with the actual state of the files listed, some of which are being modified by third-party applications.

There is, as experienced Mac OS X users know, a long history of Mac OS X having trouble keeping things in sync, especially in Finder windows in list view. At some point, things were so bad that we had to use third-party tools such as the free Nudge menu plug-in developed by Rainer Brockerhoff just to force the Finder to show files created by third-party applications.

Things have been gradually improving over time, with every new iteration of the Mac OS X operating system, and Mac OS X 10.5 brings another range of further improvements. Yet keeping Finder lists in sync can obviously be a tricky business, as this particular bug demonstrates.

Sadly, the list view mode continues to be treated as a second-class citizen, even in Mac OS X 10.5. As of Mac OS X 10.5.1, I still experience situations where the Finder fails to update the contents of a Finder window in list view from one day to the next, and lists items with a modified date of “Today” when they actually were last modified yesterday, when yesterday was “today.” This only occurs in list view, and has been a problem for several years now in Mac OS X. Apple still hasn’t addressed the issue properly in Mac OS X 10.5.

As for this bug with the untitled folder name not staying editable, it obviously will never be very high on anyone’s list of bugs to fix, be it at Apple or in the community of developers working on Camino. But it might be a symptom of a more serious flaw in the underlying mechanisms used by Mac OS X and by third-party applications to keep folder listings in sync.

One Response to “Camino and Downloads folder: Untitled folder name fails to stay editable while download is in progress in list view”

  1. ssp says:

    I am tempted to guess the following: Usually the Finder isn’t all that great (ie crap) at indicating file sizes which change in list (or any other) view. Perhaps the Camino people thought it’d be smart to kick the Finder a little to keep its display current because of that. But updating the display makes the Finder (being the buggy POS that it is) stop editing the file name in list mode.

    In principle the Finder should automatically refresh its display in all situations without losing any other status. Of course time was wasted to file bug reports on that long ago. But you know how these things don’t work. Particularly when the Finder is involved.

Leave a Reply

Comments are closed.