This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Problem with cat under bash shell

> -----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, 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.....;en-us;837665

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. 
This problem occurs because the file is incorrectly deleted when the
specified handle is closed. 

  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

  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.

Can't think of a witty .sigline today....

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]