It's not my imagination; that function is ignoring me!

There is an alias at Microsoft that is the front line for the Shell team, the one place where the important issues like build breaks and blocking issues get brought up. Since even within Microsoft so many people assume that Windows == the Shell, this alias gets to triage and appropriately redirect issues a lot, too. Raymond talked about this list late last year in this post.

And I belong to that list, so that every once in a while when someone complains about a Shell bug that is actually an internationalization bug, I can pitch in (though I am not on the official list to become a Dev O'Day or anything, it is always nice to help out if one has an area that know about!).

Also, every once in a while something interesting to blog about comes up.... :-)

Take the other day, for example. A problem was reported in Vista, with the SHLWAPI SHSetLocalizedName function, which sets the localized name of a folder. Basically it lets you set things up so that the Shell can use the SHLoadIndirectString function (which I have mentioned before) can be called.

Anyway, the problem was that sometimes it wasn't working. The function was reporting back success (S_OK), but the name was not being set. However, if the folder was made readonly, then the localized name would appear (this post by Raymond explains how the setting actually has nothing to do with the folder being read-only, and why the setting would have an effect.

On the list it was quickly determined that the change of the attribute worked from an elevated command prompt and failed from a non-elevated one, and was thus quickly determined to be a permissions issue. The caller lacked the permissions to completely succeed in making the call to SHSetLocalizedName.

Of course the problem remained -- why was SHSetLocalizedName claiming success when it had technically failed?

I asked Raymond about this, hoping for understanding of some higher purpose behind it all. He quickly set me straight:

No, it's just a bug.

I mean, who would be so crazy as to make a directory that you could create and modify files in but which you couldn't attrib +R!

At the point this error occurs SHSetLocalizedName is kind of in a fix.

It already made half of the change and got an error making the other half.

Now what do you do?

You can't undo the first half because your change to the first half overwrote what used to be there (if the file already had a different localized name).

Sure, you could remember what used to be there before you overwrote it so you could restore it afterwards, but what if you encounter an error trying to restore it!?

(or worse, what if somebody else also changed it in the meantime -- now your "restoration" is actually undoing somebody else's change)

Basically, SHSetLocalizedName got itself into a jam and does its best to crawl out from under the rubble.

One could even argue that it set the localized name just fine -- but like any situation where there is a setting and then a way to enable it, it simply hasn't been enabled yet. :-)

Technically, it seems that SHSetLocalizedName is doing its level best in the face of adversity, so perhaps there is a higher purpose here....

Anyway, we chatted about blogging about this issue. It seems worth doing since setting folder attributes is a pretty public process, and SHSetLocalizedName is a pretty public function. So anyone could run into this very same problem, depending on how the foder was created and where.

And people really should be using the function to get the job done -- manually mucking about in desktop.ini or the cache in the registry or in file attributes in an NTFS stream or the folder's aura or its astrological sign or whatever other sneaky, undocumented method developers find to do work here can break anytime the underlying implementation of the functionality changes.

For the record, such a change did happen in Vista, which kind of proves the point, right?

Anyway, to answer the paranoia implicit in the title of the post -- the function isn't ignoring me, it is simply not pointing out the flaw in my approach when I didn't do everything right on my side. And the Shell is your friend -- what kind of friend is going to nitpick every little detail of a non-atomic operation? :-)

And now you can prove your worth to the Shell by calling the function to get the work done -- what kind of friend is going to ignore the polite ways to communicate and instead rifle through the drawers while your friend isn't looking?

This post brought to you by ऑ (U+0911, a.k.a. DEVANAGARI LETTER CANDRA O)