Guest Post: The Case of the FrontPage Error

re: Guest Post: The Case of the FrontPage Error

Erwin Ried — Wed, 14 May 2008 20:48:14 GMT

Cool, and better for Tony if the prize was a signed book!

Just a little typo: "from the parent to _propoage_"

re: Guest Post: The Case of the FrontPage Error

markrussinovich — Wed, 14 May 2008 20:53:11 GMT

Thanks for the feedback and the correction, Erwin.

re: Guest Post: The Case of the FrontPage Error

markrussinovich — Wed, 14 May 2008 20:53:36 GMT

Tony did get a signed book (I indicate that in the introduction).

Thanks for the feedback and the correction, Erwin.

re: Guest Post: The Case of the FrontPage Error

wmcglinn — Thu, 15 May 2008 02:20:49 GMT

G'day Mark,

just one small correction: "When you “Move” a file 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." This is only true when moving files that reside on the same volume (or partition), moving *between* NTFS volumes inherit permissions. A small correction but very crucial to understanding how NTFS permissions differ when moving and copying within or between volumes.

Wayne McGlinn

Brisbane, Oz

re: Guest Post: The Case of the FrontPage Error

Joel Peterson — Thu, 15 May 2008 02:34:35 GMT

The following line set off an exchange in our internal developer email list:

"When you “Move” a file 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."

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():

File.Copy("C:\\Users\\jpeterson\\Desktop\\error.txt", "C:\\Users\\jpeterson\\Desktop\\error2.txt");

File.Copy("C:\\Users\\jpeterson\\Desktop\\error2.txt", "C:\\temp\\copied.txt");

File.Move("C:\\Users\\jpeterson\\Desktop\\error2.txt", "C:\\temp\\moved.txt");

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)?

re: Guest Post: The Case of the FrontPage Error

markrussinovich — Thu, 15 May 2008 02:58:59 GMT

Hi Wayne,

That's not really a correction, but a clarification. I've modified Tory's text to note that he moved the file within the same volume.

-Mark

re: Guest Post: The Case of the FrontPage Error

Ali — Thu, 15 May 2008 05:17:53 GMT

Joel Peterson,

I think "Desktop" file is different,i reproed your saying.

re: Guest Post: The Case of the FrontPage Error

WDoser — Thu, 15 May 2008 14:42:55 GMT

Joel, 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.

Mark, thank you very much for your tools. :)

re: Guest Post: The Case of the FrontPage Error

S. Mahdi Veradi — Thu, 15 May 2008 22:24:11 GMT

I think the matter of permissions and their intricacies needs to be clarified a bit. Here is what I have learned:

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.)

Unfortunately, the example posted by Joel Peterson also does not help clarify matter with these two new versions of Windows, since it is in C# and therefore uses .NET Framework not Windows API. .NET Framework is supposed to have the same behavior on all versions of Windows; unless otherwise documented in its documentations.

- S. Mahdi Veradi (MCP)

re: Guest Post: The Case of the FrontPage Error

Chris Hutchcroft — Sat, 17 May 2008 19:26:00 GMT

This move problem for site content is not limited to FrontPage, I find it's a common problem when moving any site content.

I get a lot of sites come as installers that install to C:\Program Files\blah\ and don't offer an option to set that folder nor set permissions correctly. When moving to the managed site content folder (C:\Inetpub\ or C:\Sites\ or whatever), weird things happen.

90% of these weird things are because the content was moved, not copied. This is now our first step in troubleshooting. Our second step as always is Process Monitor.

Pre-emptive rebuttal - this isn't an issue of your content is on a different volume following best practices, if you move from C:\blah to E:\Sites the move is a copy.

re: Guest Post: The Case of the FrontPage Error

stryqx — Mon, 19 May 2008 17:54:56 GMT

Nice piece if sleuthing.

Although the error message is still an indication of just how bad software developers are at writing meaningful error handling code.

It's still insane how we have to instantly dive down to the bottom layer to solve these simple problems.

And don't even get me started in the bubbling up of a 32-bit error number to the end user...

You need to post more often

David — Mon, 19 May 2008 20:06:06 GMT

I'm still waiting for the "Case of the mysterious idle 12:10am Vista csrss related disk activity that lasts 20 minutes and doesn't show up in procmon even with filters turned off and isn't defrag, system restore, indexing, windows update, superfetch, thumbnail cache updates, trustedinstaller, swap usage, or the drive's idle self test."

re: Guest Post: The Case of the FrontPage Error

Joel Peterson — Mon, 19 May 2008 20:42:30 GMT

Apologies to Troy for reading too fast and using the wrong name in my post.

I'd still like to get some clarification why the behavior is different between right-click plus drag-move from the Desktop to a folder versus right-click plus drag-move from within a single Windows Explorer window.

re: Guest Post: The Case of the FrontPage Error

Grammar maniac — Sat, 24 May 2008 11:52:28 GMT

"I wasn’t feeling motivated to become a FPSE expert just to solve this one problem."

should read

"I wasn’t feeling motivated to become an FPSE expert just to solve this one problem."

Not so fast...

Roastbeef — Mon, 26 May 2008 01:42:26 GMT

Grammar maniac,

If you consult your Chicago manual (or similar) you'll find that the criteria picking 'a' versus 'an' depends on how the phrase *sounds*, not the simple (but incorrect) idea of looking at whether the word begins with a consonant or a vowel.

If 'FPSE' is pronounced as "eff-pee-ess-eee", then using 'an' would be correct.

re: Guest Post: The Case of the FrontPage Error

tOM Trottier — Mon, 26 May 2008 21:11:32 GMT

Since copy resets the permissions, it looks like you just need to move files to a new folder then delete the original folder and rename the new folder.

Managing permissions is like herding snakes...

tOM

re: Guest Post: The Case of the FrontPage Error

romeo — Tue, 27 May 2008 01:29:52 GMT

thank God we have this kind of environment of bloggers. Im new to this and i hope i can contribute some idea that can help beginners and computer systems enthusist like me. More power to bloggers. And also you can create for auto repair bloggers. Thank you very much. romoe

re: Guest Post: The Case of the FrontPage Error

Quitch — Wed, 28 May 2008 00:38:47 GMT

The blog says to keep submitting your troubleshooting cases along with screenshots and log files... but there's no address, and the e-mail page doesn't allow for attachments.

I'm sure it's an open secret to regulars, but might be worth mentioning for those not in the know ;)

re: Guest Post: The Case of the FrontPage Error

RAWNet — Fri, 30 May 2008 12:25:02 GMT

Hi All, I am just wondering where the anonymous account gets added in this example, as in the sample images I see no addition of the IUSR_XXXX account (which I assume would need write permissions to create the log file) before forcing inheritance - or am i missing something obvious?

re: Guest Post: The Case of the FrontPage Error

Stefan — Sun, 16 Aug 2009 18:50:22 GMT

Excellent instructions. I tested the Process Monitor and it solved my problem of missing security settings!