How do the FILE_SHARE_* bits interact with the desired access bits?

Nasty table...

Marc Wallace — Tue, 11 May 2004 18:19:00 GMT

They really should have had borders on those table cells. Looks truly unusable in Opera.

Looks like pretty clear boolean logic, too. I like that share and access rights are separated.

Cool to show how you can delete while open

David Kafrissen — Tue, 11 May 2004 20:16:00 GMT

Greetings,

It is this kind of thing that makes Win32 more powerful than UNIX, because traditional UNIX does not handle file sharing to well.

It is a cool trick to show students that you can open a file for reading two different ways, one in which you can delete the file from the file explorer while it is open and being read/written to in your program, and in another, you cannot delete the file in file explorer while it is open and being read/written to from your program. This all depends on which flags you choose when you open the file.

re: How do the FILE_SHARE_* bits interact with the desired access bits?

Cooney — Tue, 11 May 2004 20:27:00 GMT

> It is a cool trick to show students that you can open a file for reading two different ways, one in which you can delete the file from the file explorer while it is open and being read/written to in your program, and in another, you cannot delete the file in file explorer while it is open and being read/written to from your program. This all depends on which flags you choose when you open the file.

It's too bad that it isn't realized fully - in Unix, I can upgrade a library by copying the new version over it (or changing a link). This doesn't affect running programs, only new ones. The analogous situation involves SFP, backup directories, and a reboot. Much less satisfying.

re: How do the FILE_SHARE_* bits interact with the desired access bits?

Raymond Chen — Tue, 11 May 2004 20:31:00 GMT

I would think that on UNIX, overwrite would be a problem (since the inode hasn't changed); you need to do a delete/copy or a rename/copy.

SFP protects only OS files. Applications shouldn't be messing with OS files anyway.

re: How do the FILE_SHARE_* bits interact with the desired access bits?

Dan Maas — Tue, 11 May 2004 23:28:00 GMT

On UNIX you'd create the new version of the file under a temporary name and then rename() to the final name, which also has the benefit of being atomic. (although user-interface wise, I can see the logic of why Windows generally won't let you delete a file that a program has openened)

Is there a way to atomically replace a file on Windows?

re: How do the FILE_SHARE_* bits interact with the desired access bits?

Jeremy Croy — Wed, 12 May 2004 00:02:00 GMT

Rename the old version something else, then put the new one on the system.

re: How do the FILE_SHARE_* bits interact with the desired access bits?

Norman Diamond — Wed, 12 May 2004 03:44:00 GMT

There is an immense difference between the description in the base note and the description that programmers ordinarily find in MSDN such as http://msdn.microsoft.com/library/en-us/fileio/base/createfile.asp

There are also differences between the table which Mr. Chen provided a link to, and the MSDN page on CreateFile.

Furthermore, the MSDN page on CreateFile doesn't even give a link to the MSDN page that Mr. Chen gave a link to. Furthermore, the MSDN page on CreateFile describes a flag FILE_SHARE_DELETE which the other page doesn't describe. Could it possibly be that the table was outdated, wasn't even correct at the time it was published, and has been forgotten about by MSDN maintainers?

Let's see what CreateFile really says:

> FILE_SHARE_DELETE Enables subsequent open
> operations on the object to request delete
> access. Otherwise, other processes cannot
> open the object if they request delete
> access.
> Windows Me/98/95: This flag is not
> supported.
>
> FILE_SHARE_READ Enables subsequent open
> operations on the object to request read
> access. Otherwise, other processes cannot
> open the object if they request read
> access.
>
> FILE_SHARE_WRITE Enables subsequent open
> operations on the object to request write
> access. Otherwise, other processes cannot
> open the object if they request write
> access.

Notice the effect on SUBSEQUENT open operations. If someone else has a file open with FILE_SHARE_READ | FILE_SHARE_WRITE, and we want to open it for GENERIC_READ | GENERIC_WRITE but not share it with anyone else, we get the file and the previous opener still has the file. Only SUBSEQUENT attempts to open for reading or writing will fail. This is quite different from Mr. Chen's statement:

FALSE> So suppose you omit the flag,
FALSE> indicating that you don't want to let
FALSE> others read the file. Then when you
FALSE> attempt to open it yourself, the open
FALSE> will fail if anybody else has the file
FALSE> open for reading.

The wording of CreateFile also provides a number of other undesirable effects. For example, we want to open a file and allow FILE_SHARE_READ. Subsequently someone else want to open it with GENERIC_READ | GENERIC_WRITE. MSDN says they get it, because their request includes GENERIC_READ. The description of FILE_SHARE_DELETE is still so unclear that maybe developers of Windows file systems couldn't even follow it properly, which might explain why sometimes you can't delete a file because of a sharing violation even though no process has the file open.

This is the kind of thing that makes Windows less powerful than every other OS on the market. Neither Unix nor any other modern OS has fully copied the permissions structure that Honeywell got right 40 years ago, but at least each other modern OS is self-consistent. In Unix you have to do arcane things to get file operations performed reliably, but in Windows you have to do even worse arcane things.

(I'm again too busy to catch up with Mr. Chen's recent writings, but this one was just too important to let pass.)

re: How do the FILE_SHARE_* bits interact with the desired access bits?

Raymond Chen — Wed, 12 May 2004 05:11:00 GMT

The FILE_SHARE_* flags prohibit subsequent opens. They also prevent the current CreateFile from succeeding if they conflict with prior opens. This is implied by the fact that the previous GENERIC_* open prevents subsequent opens from succeeding if they do not specify FILE_SHARE_*. The docs are correct but leave a lot of the logical deductions to you, the reader.

re: How do the FILE_SHARE_* bits interact with the desired access bits?

Steven Youngs — Wed, 12 May 2004 08:22:00 GMT

>Is there a way to atomically replace a file on Windows?

There is a Win32 function called ReplaceFile. Not sure if it's atomic or not.

re: How do the FILE_SHARE_* bits interact with the desired access bits?

Jordan Russell — Wed, 12 May 2004 08:54:00 GMT

> Is there a way to atomically replace a file on Windows?

If I'm not mistaken: MoveFileEx(..., ..., MOVEFILE_REPLACE_EXISTING)

re: How do the FILE_SHARE_* bits interact with the desired access bits?

jojjo — Wed, 12 May 2004 11:12:00 GMT

Your comment about checkmarks is interesting.
In Sweden a checkmark is the standard way of marking an error on a test or a paper. The first time my mother saw those old Borland messageboxes with a checkmark on the OK button and an X on the Cancel button she pressed Cancel because the checkmark to her denoted that there was something wrong and the X that she accepted (there's a swedish expression "kryssa för" (cross for) which means to check something).

re: How do the FILE_SHARE_* bits interact with the desired access bits?

Raymond Chen — Wed, 12 May 2004 17:48:00 GMT

"Subsequently someone else want to open it with GENERIC_READ | GENERIC_WRITE. MSDN says they get it, because their request includes GENERIC_READ."

No, they don't get it because their request includes GENERIC_WRITE and you didn't allow write.

In order for the open to succeed, ALL requirements must be met. This is such a basic rule that I'm surprised it needed to be mentioned explicitly. Did you serious believe that "Enables subsequent open operations on the object to request read access." means that if you match the read sharing modes, then all other security/sharing flags become irrelevant? Did you really think that it would override the ACLs on the file?

Here's another basic rule that is so obvious that it isn't mentioned explicitly: The sharing modes applied to a handle are effective only as long as the handle remains open.

In fact the addition of "subsequent" was my attempt to state something that should have been blatantly obvious: CreateFile is not a time machine. Some people apparently thought that the absence of "subsequently" meant that you could use CreateFile to revoke previously-opened handles...

At some point you have to decide at what point you should stop saying obvious things in the documentation and leave the reader to use their own brainpower.

re: How do the FILE_SHARE_* bits interact with the desired access bits?

4nd3r$ — Wed, 12 May 2004 23:22:00 GMT

>If I'm not mistaken: MoveFileEx(..., ..., MOVEFILE_REPLACE_EXISTING)

...on NT, on 9x u need to write to wininit.ini (without using the ini file functions)

re: How do the FILE_SHARE_* bits interact with the desired access bits?

Jordan Russell — Thu, 13 May 2004 01:36:00 GMT

His question was how to atomically replace a file, a la Unix's rename(), not how to replace a file on reboot.

re: How do the FILE_SHARE_* bits interact with the desired access bits?

Norman Diamond — Thu, 13 May 2004 02:55:00 GMT

A few metarules:

Specifically stated rules override basic rules.

Stated rules override intuitive rules.

The correctness of a basic rule or intuitive rule does not change an incorrect specific rule or incorrect stated rule into a correct one.

I am glad to see that these are bugs in the MSDN library rather than in the OS. Nonetheless, if the MSDN library is to be useful, its bugs must be fixed. "RTFM" has to mean that TFM is to be R'd rather than F'ed.

re: How do the FILE_SHARE_* bits interact with the desired access bits?

Raymond Chen — Thu, 13 May 2004 03:30:00 GMT

Okay then: You tell me how that section should be written, now that you understand what FILE_SHARE_READ means. Since apparently nothing I write meets your high standards.

Why is it FILE_SHARE_READ and FILE_SHARE_WRITE anyway?

Larry Osterman's WebLog — Thu, 13 May 2004 20:11:00 GMT

Deleted but not yet forgotten

The Old New Thing — Mon, 07 Jun 2004 17:02:00 GMT

What happens when you delete a file while it is open?

Determine share mode of opened file handle

Programming and Peace of Mind — Wed, 07 May 2008 08:09:33 GMT

If there is a file already opened and you also want to open it, you need to know the share mode: FILE_SHARE_*