In my last post, I talked about the installation experience of Windows Vista RC1. Well the overall experience was definitely positive there were a few bugs that I found from build 5384 and still seemed not being fully functionally correct. The first bug I want to mention here is, I call it “Ghost” folder. Typically, when you delete a folder, you would expect everything inside that folder to be gone. However, this is not always the case in Windows Vista RC1. When you create nested folders in the explorer and try to delete the root folder you created (while having the explorer still open) using command “rmdir /s/q”, a few strange things will happen.
- Suppose we created folders test\1\2\3\4 under c:\ and you are currently viewing the contents within folder “3” in explorer. When you try to run the rmdir command (rmdir /s/q c:\test), you will get the message test\1\2 -“The directory is not empty” error and only directory “3” is deleted. Well, of course it is not empty, that’s the whole point we are running rmdir /s/q isn’t it?
- This is only the beginning of the problem however, when you run rmdir /s/q c:\test again, everything is deleted. You can verify this by typing dir c:\test and you will see the folder is gone. Or really? Well, the explorer window still caches the folder structure as you can see in the screen above. Now if you create folders under test\1\2\3 say we created a 4 and then nested another folder “New Folder” and run a dir /s c:\test again, you will see all the folders are back! Since we never explicitly create the test\1\2\ directory structure, that’s why I call this problem a “ghost” folder problem.
Well, maybe item 2 was intended as a feature (it really shouldn’t be one because of the inconsistencies between the explorer window and the command prompt), but the message given in item 1 is totally misleading.
Another interesting problem I found is how the command prompt handles crashes. To see what I mean, fire up a command prompt in Windows Vista, and enter debug mode (yes, the DOS time utility is still here), and type in “f 0000:0000 ffff ff”. What this command means is to fill the first 64K of memory address with ff. Back in DOS time, this is a sure technique to cause the whole system crash since some important portions of the OS (e.g. interrupt tale) resides within the lowest 64K in memory. But in a 32bit protected environment, this is no longer the case. If you try the above command in Windows XP (or 2000), you will simply see the debug prompt being halted as if nothing has happened. But in Windows Vista, you get the following message:
Whether or not these “bugs” are intended as “features”, it seems that there’s still a lot of work to be done before Windows Vista can be released.
