What's an API designer to do?: redux

Previously, I brought up a hypothetical API discussion to see what different people thought about the idea. The basic premise of the discussion was: what do you do when you've published an API to interact with something, and then the rules for that interaction change?

Now I want to make that hypothetical discussion more concrete with a real world issue that's interesting to me. But, I want to preface this with: this post has no bearing on reality. Anything we discuss here is purely academic. I'm in no way saying that REAL Software is going to do something, change anything, drink anything, purchase anything, deploy anything or take over a third world country. Basically: I don't want to hear any "Aaron said" crap at my day job. Got it? ;-)

The hypothetical I discussed before is a generalization of the problems faced by FolderItem.IsWriteable on Windows Vista. Vista introduced this concept called folder virtualization as a mechanism to support older application which did bad things. These older applications made the totally incorrect assumption that the user always ran as admin, and the user could always write to some directories (or registry keys, etc). So, as a back compat measure, the OS virtualizes access to these resources. When a poorly-written application tries to make a file under the Program Files directory, the OS doesn't actually modify the Program Files directory -- instead it modifies the Users\user name\AppData\Local\VirtualStore\Program Files directory. It virtualizes the access, basically.

Before I move on, I'd like to point out one fact (not opinion). These applications were already broken. Any application which assumes (1) the user is an admin, or (2) it can write a file anywhere, is an application that has a bug in it. These are totally incorrect assumptions. So folder virtualization isn't a feature -- it's a workaround for buggy applications.

So the question now becomes: is Program Files writeable or not?

From one perspective, it is. When I say "make a new file here and write to it", a file is created (somewhere), and data is written to it. However, that perspective ignores the "here" problem: the file isn't created where you asked it to be created. It's been created somewhere else entirely! So which is it? Is the FolderItem writeable or not?

My personal perspective on this is that IsWriteable should return whether that location is writeable or not, and a virtualized folder is *not* writeable unless you have the proper access rights to it. If you are not an elevated user, then Program Files is *not* writeable.

My reasoning for taking this stance is fairly simple: if you didn't care about the answer, you wouldn't ask the question in the first place. If you care enough to ask, you should be given the correct answer. The question IsWriteable is asking isn't "will the write operation succeed." The question it is asking is "is this file/folder something I have permission to write to." If you wanted the answer to the previous question, the procedure is quite simple: try to write to the file!

This means that (from my perspective) REALbasic's FolderItem.IsWriteable is returning incorrect information. It's checking the answer to the "will this write work" question on Windows. This has some very interesting ramifications. For instance, it means that you cannot detect folder virtualization with that API, so applications trying to be correct will actually end up being incorrect instead. When the helpful application wants to list only writeable directories, Program Files will show up, which is not what the OS wants (remember: it's just trying to shim up bad applications).

So, with this concrete example of what I was previously talking about, how have your opinions changed? What do you think the proper behavior of FolderItem.IsWriteable should be?