Mail Archives: cygwin/1997/01/24/18:52:46
root wrote:
>
> > find uses the lstat system call, and the cygwin implementation
> > opens the file and actually reads it in order to see whether it is a
> > symlink (now you know why find takes so long). symlink_check dies
> > opening a file opened for writing (a piece of Miscrosoft brilliance
> > that helps unix weenies win the advocacy wars).
> [snip]
> > Or, somehow tell the OS to allow files open for writing to be open
> > for reading.
>
> HINT:
> ----
> HANDLE CreateFile(
> LPCTSTR lpFileName, // pointer to name of the file
> DWORD dwDesiredAccess, // access (read-write) mode
> DWORD dwShareMode, // share mode <<<<<<<<<<<<<<look this <<<<<<<<<<<<<<
> LPSECURITY_ATTRIBUTES lpSecurityAttributes,// pointer to security descriptor
> DWORD dwCreationDistribution, // how to create
> DWORD dwFlagsAndAttributes, // file attributes
> HANDLE hTemplateFile // handle to file with attributes to copy
> );
> Parameters
> [snip]
> dwShareMode
> Specifies how this file can be shared. This parameter must be some combination
> of the following values:
> Value Meaning
> 0 Prevents the file from being shared.
> FILE_SHARE_READ Other open operations can be performed on the file for
> read access.
> FILE_SHARE_WRITE Other open operations can be performed on the file
> for write access.
>
> I suspect strongly that bash when opening the redirection file is just using
> zero, meaning no share.
Well, your suspicions are wrong. All CreateFile calls in cygwin use
FILE_SHARE_READ | FILE_SHARE_WRITE, except the one in symlink_check,
which has only FILE_SHARE_READ. The latter is not good, since it both
blocks the open from working if the file is open for writing and it
blocks others from opening the file for writing while symlink_check is
reading it.
Files open by bash (or any other cygwin program) can be read and written
by others, as a simple experiment can confirm. However, cmd.com (I
haven't tried command.com) does block writers to files it is writing
(i.e., uses FILE_SHARE_READ) but does not block writers to files it is
reading (i.e., uses FILE_SHARE_READ | FILE_SHARE_WRITE). Of course, it
is silly for cmd.com to block writers to files it opens for writing, but
c'est la vie. (This wouldn't be such a problem in an intelligently
designed system that allowed other opens to block, rather than just
fail, when a file is locked).
Meanwhile, symlink_check should be fixed to use
FILE_SHARE_WRITE|FILE_SHARE_READ so that it doesn't block other opens
while it is checking symlinkedness. At the very least, it should
treat a sharing error as meaning that the file is a regular file,
as it most likely is if someone is writing to it.
--
<J Q B>
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -