So last weekend I was planning the best "breakfast-night" for dinner ever.
I'm known in the family for my wicked-awesome French toast. So I had planned a great dinner of special scrambled eggs, bacon, and the French toast.
The first two were no problem...then I began making the French toast batter. I added all the normal (and my secret) special ingredients. Yummy! Then for the topper I reached for the cinnamon spice jar and topped off the now dunked and cooking slices sizzling on the flattop grill.
Only one problem.
It wasn't cinnamon I had grabbed, but cayenne pepper powder. My eyes must have been tired.
Lavie thought the resulting dinner was much too spicy to eat. Alvis kindly ate two or three pieces declaring it surprisingly good. I had to agree, but only if done with moderation. The sweet syrup worked well with the spicy flavor.
So this week I had to have a re-do. I recreated the menu again, this time carefully reaching for the cinnamon spice miller, just to be extra safe....only I had forgotten that I had removed the mill part and the cap was loose on the top.
This time I was greeted with a shower of cinnamon chunks over the counter and in the batter. Luckily these were quickly fished out and cleaned up.
Had to end up using the two-year old jar of ground fake-cinnamon instead. Checked twice before application.
It was still good.
Here are some Microsoft related posts from the Web grinder I found interesting to note this past week.
A Look Behind the OEM Driver Curtain
The key to Windows success? It’s all about the drivers - Ed Bott’s Microsoft Report
Mr. Bott takes us on a quick two-page review of how drivers and hardware come together to get on your Windows system...and the pitfalls we face when users must rely on OEM manufactures to produce and distribute them.
IE and XP SP 3 What You Need to Know
IEBlog : IE and Windows XP Service Pack 3
You only need to care if you plan on rolling back your current version of IE after you install XP SP3. Here's the gist:
XP SP3 ships with IE 6;
If IE 6 is installed, no changes or impact.
If IE 7 is installed, XP SP3 will install, BUT you will no longer be able to uninstall IE 7 to roll back to IE 6 under XP SP3. To roll back, you must uninstall XP SP3, then roll back to IE 6, then reinstall XP SP3.
If IE 6 is installed, and you install XP SP3, THEN upgrade to IE 7, you can roll back to the "newer" IE 6 in XP SP3 with no issues.
If you have IE 8 beta installed on your XP SP2 system, Windows Updates will not offer XP SP3 to you (by design). You must first roll-back IE 8 Beta to a previous version of IE first. If you do a manual install of XP SP3 on top of an existing install of IE 8 beta, you can't remove IE 8 beta after that! Recommendation is to roll back to IE 7 or 6, then install XP SP3, then reinstall IE 8 Beta so you can remove it later if you wish.
Nice and simple isn't it?
Branding IE in XP SP3
I haven't seen or had a need for a "branded" IE installation since my early Windows 2000 support days. We decided to rollout some IE 6.0 releases with the agency name as part of our imaging and IE upgrade project way back when. More work than it was worth (fun though it was).
Turns out that XP SP3 mucks up the process a bit on producing custom IE7 packages unless you use the new Internet Explorer Administration Kit 7 (IEAK7).
IEBlog : Installing Branded IE7 on Windows XP Service Pack 3
Although likely to be rare, if someone you support does get the XP SP3 upgrade, and later tries to use one of these "branded" IE7 setups (say from a broadband provider), they may get the following error:
“Process 'xmllitesetup.exe /quiet /norestart /er /log:C:\WINDOWS' exited with exit code 61681”
Reason according to IEBlog is that the IE7 installer package is attempting to toss an older file version on top of a newer one, something the system won't allow.
Now you Know!
New Mystery Solved at Mark's Blog
Always a source of entertainment and good Windows troubleshooting techniques, this latest "guest post" installment from Mark Russinovich's blog hunts down problems in FrontPage.
The Case of the FrontPage Error - by Windows Detective Troy Wolbrink
Troy illustrates the easy use of Process Monitor to find a file-creation error. A few security setting changes on the original file resulted in the fix.
What I found most useful to learn from the post, was not this technique, but a comment at the end regarding how file properties are handled between "move" and "copy" actions on the same volume:
Looking back I believe that this problem occurred because I used Windows Explorer to “Move” and not “Copy” the csv file into place. I did some more tests to confirm this. When you “Move” a file within the same volume using Windows Explorer, the file permissions are moved with it. When you “Copy” a file using Windows Explorer, it creates a new file that inherits permissions from the target folder. If I had originally performed a “Copy” this problem would have never happened.
Other interesting bits from the comments:
I immediately tried to reproduce this behavior on Windows Vista x64 SP1. I created a folder (c:\temp) with very unique permissions. I used right-click and drag-copied from my desktop to the c:\temp folder window and it did inherit the permissions. However, when I used right-click and drag-moved the same file to to the folder, it also inherited the permissions of the folder. This is at odds with the behavior described by Tony.
I then proceeded to make a very simple C# sample (.NET 3.5) to do the same thing, as a developer asked if the behavior described by the guest was the same for MoveFile() and CopyFile():
...
This sample did reproduce the behavior described by Tony. The file copied.txt did inherit the folder’s permissions, but the file moved.txt kept its original permissions from my Desktop folder.
That didn't make any sense, so I went back and read this blog post and thought about the interpretation of "Windows Explorer". I then used the true-blue Windows Explorer (Windows Key + E) and only moved the file within that window from my Desktop folder to c:\temp. It exhibited the behavior described by Tony and did not inherit the permissions of the folder. Likewise, copying the file only through the Windows Explorer window resulted in the file inheriting the folder's permissions.
So what's going on here? Did the behavior in the Windows shell change at some point? Or are we looking at a bug? Is there a spec for the expected behavior for each scenario, and have these behaviors changed with different releases of Windows (RTMs and Service Packs)? - Joel Peterson
...there is an KB article about the not inherited permissions when moving folders on NTFS Partitions:
http://support.microsoft.com/kb/320246/en-us/
It also states that this behaviour has changed in Vista and Windows 2008.
This sometimes also happens on Win2000/2003 fileservers when Users are moving folders on the same share. To prevent problems I'm using Mark's AccessEnum to make regular checks for permissions that are not inherited correctly within the shares. - WDoser
As mentioned above, Windows API, by default, retains all of the file and folder permissions when you move them from one parent folder to another parent folder on the same NTFS volume. For copy operation and move operations to another volume, the destination file always have a new set of permissions, all inherited from its parents.
The reason is obvious to a developer: When you move a file within a volume, no physical data transfer seems to occur; Apparently, Windows only changes the volume Master File Table so that the intended files and folders belong to a new directory entry. This means that Access Control Lists (ACLs) remain unaltered, so even if your Access Control Entries are acquired from a parent. Now, it is arguable whether or not the inherited permissions should be updated with the new parent or not, and whether there is a bug here or not.
However, during a copy operation, or a move operation to another volume, a physical data transfer from one location of the hard disk to another is inevitable. Therefore, Windows API has to build a new ACL for each file and folder entry. These new entries turn out to have permissions inherited from parent.
As demonstrated by Joel Peterson, .NET Framework has the same behavior as Windows API.
Windows Explorer (Windows Shell) tends to deviate from this behavior. According to Microsoft Knowledge Base:
1. On Windows XP, when Simple File Sharing is enabled (default), Windows Explorer always makes sure that all ACLs are reset. This an intended feature that makes using Standard User Accounts in homes and small-business environments more convenient. Note that this only applies to Windows Explorer and Windows Shell, so file operation behavior of programs like Command Prompt are not affected by Simple File Sharing setting.
2. Windows XP, when Simple File Sharing is disabled (domain default) and on Windows Server 2003, Windows Explorer does not alter file and folder permission. This is meant to be an intended defense-in-depth security feature.
So far I don't know the exact behavior of Windows Vista and Windows Server 2008. The KB article which WDoser introduced indicates that Windows now updates ACEs which are inherited from parent but does not explain whether it is a Windows API behavior or only a Windows Shell behavior. To make matter worse, the Applies To section says this article is applied to all editions of Windows Server 2008 but not Windows Vista. (I think it's time I investigate this matter a bit more.) - S. Mahdi Veradi (MCP)
Got to confess...I almost never use "move" and almost always use "copy" but I have never considered the real difference that makes with file permission security settings, especially between different volumes.
Now Serving: Chef Bill's House Special
I really like reading Bill Pytlovany's "Bits from Bill blog. While he does post regularly regarding issues and updates for his GSD recommended WinPatrol freeware/$ system monitoring and security product, he also mixes it well with great tips and observations on Windows and life-in-general.
This post was quite timely: Windows XP SP3, The Good, the Bad and the Ugly
Good: XP SP3 may indeed make some minimal performance improvements.
Bad: Some HP AMD pc's are taking after XP SP3 upgrades. Link to Jesper’s Blog with his solution.
Ugly: See the summary earlier in this post regarding IE and XP SP3
I still haven't gotten around to upgrading Lavie's Compaq laptop that is running XP Home SP2 to XP SP3. It also has a AMD processor. I didn't have any problems with the AMD chip in my Shuttle desktop system. So I am hopeful this one will go well. Instead of using the full installer, I think I will allow it to flow down via Windows Updates, just for kicks.
--Claus
No comments:
Post a Comment