> -----Original Message----- > From: cygwin-owner On Behalf Of Lionel Barnett > Sent: 16 September 2004 13:02 > To: cygwin > Subject: Re: Problem with cat under bash shell > > --- Corinna Vinschen <corinna-cygwin SPROING! cygwin WHIZZ! com> wrote: > > On Sep 16 10:47, Lionel Barnett wrote: > > > --- Corinna Vinschen <corinna-cygwin OOPS! cygwin SPLAT! com> wrote:
Hey Lionel, read http://cygwin.com/acronyms#PCYMTNQREAIYR, let's not feed the spam harvesters huh? > > What bash does is this: It opens a temporary file in /tmp > which gets > > everything you type into the here script up to the EOF. Then it > > duplicates the handle to become stdin for the still to be called > > `cat' > > process. Next, it unlinks the file. Unlink is implemented as > > > > h=CreateFile(FILE_FLAG_DELETE_ON_CLOSE); > > CloseHandle(h); > > > > This should result in removing the file as soon as all open handles > > to > > the file are closed. That works, but for some reason also the > > ReadFile > > call in cat fails as above. I suspect 'doze simply isn't able to rely on a remotely mounted fs implementing delete-on-final-close semantics, since the remote mount could be NFS on a Unix box, or Novell over IPX/SPX, or Samba on Linux. And it can't simply delete the file itself when the handle is closed, even if it has no other handles to the same file, because there might be another remote user on a different client with an open handle to that file who wouldn't like it to vanish under their feet. So maybe there's some bodge here that denies access. Ah! Gottit! Well, looks like my guess wasn't right..... http://support.microsoft.com/default.aspx?scid=kb;en-us;837665 |>---------------------<!snip!>---------------------<| Unexpected results may occur when you use the CreateFile function and the FILE_FLAG_DELETE_ON_CLOSE flag in multiple processes to programmatically access a file that is located on a remote Microsoft Windows Server 2003-based computer. When you use the CreateFile function and the FILE_FLAG_DELETE_ON_CLOSE flag to open and then close a file that has other handles that are still open, you receive the following error message: Error No 59: An unexpected network error occurred. CAUSE This problem occurs because the file is incorrectly deleted when the specified handle is closed. |>---------------------<!snip!>---------------------<| So, if the file has been deleted too soon, that would explain why subsequent calls to ReadFile find the whole matter a little perplexing..... Lionel, is your server win 2003? If so, there's a hotfix for the problem at the above page. > > I don't know how to fix this right now, but the workaround is simply > > to have /tmp always be a local directory. > > Thanks for the information, Corinna. Actually, what surprises me most > is that this issue has not been reported more frequently. If it really is down to this w2k3-specific issue, that would be why in itself; w2k3 is fairly new, not a lot of cygwin-users are running with it yet, and so we're only starting to see the problems begin to show up recently. The fact that mounting your /tmp on a remote drive is a pretty rare thing would be another reason. Remote home dirs, yes, remote /bin dirs yes, remote /tmp...... not so commonly done. Owing to a) there's generally no need nor use for sharing the contents of /tmp with other users and b) it gets used pretty heavily and mostly for temporary files and data that are going to be needed again imminently, so for efficiency purposes it would be nice if the data didn't have to make a round-trip across the network to a server and then back again when it could just stay on your local machine where it's needed in the first place. cheers, DaveK -- Can't think of a witty .sigline today.... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
