From: jqb AT netcom DOT com (Jim Balter) Subject: Re: file sharing during write 24 Jan 1997 18:52:46 -0800 Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <32E9480A.374C.cygnus.gnu-win32@netcom.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01Gold (WinNT; I) Original-To: root Original-CC: gnu-win32 AT cygnus DOT com Original-Sender: owner-gnu-win32 AT cygnus DOT com 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 <<<<<<<<<<<<< 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. -- - For help on using this list, send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".