delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/1999/10/21/08:06:47

Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
Message-ID: <19991021120802.18332.rocketmail@web117.yahoomail.com>
Date: Thu, 21 Oct 1999 05:08:02 -0700 (PDT)
From: Earnie Boyd <earnie_boyd AT yahoo DOT com>
Reply-To: earnie_boyd AT yahoo DOT com
Subject: Re: Mmap problem
To: Steve Jorgensen <steve AT khoral DOT com>, cygwin AT sourceware DOT cygnus DOT com
MIME-Version: 1.0

--- Steve Jorgensen <steve AT khoral DOT com> wrote:
> 
> 	I'm trying to port Khoros Pro 2001 to NT using cygwin, and
> 	am having a problem with the mmap call.
> 
> 	Khoros has a transport abstraction that makes using mmap, tcpip,
> 	file, pipes, or memory all look like a standard unix file, allowing
> 	users to use our k* file i/o calls to read and write to each
> 	different kind of transport.  Anyway, the mmap transport, in order
> 	to avoid excessive resizing, forces the underlying mmap'ed file
> 	to grow more than the write call needs.  At close time, we
> 	ftruncate the file back to the size it's supposed to be.  The
> 	problem is that ftruncate is returning with an access error.
> 	This works on all the unix systems we've ported to.  
> 
> 	I've tried the ftruncate both before and after the munmap call
> 	with the same results.  Any ideas what else I can try, or am I
> 	just out of luck?
> 

This is an issue with the underlying file system.  Assuming that it can be
done, you must have all accesses to the file closed.  Win32 will not allow such
changes to an open file, even if you are the one that has it open.  I think I
remember that there is coding in cygwin to queue operations on a file that fail
due to an open fd to the file, so this could be a bug in that related coding.

I'm not in a position to test theories or grab my documentation currently, but
this should get you started in finding a fix/workaround.  I'd suggest that you
look to see if the ftruncate function exists in the VC++ runtime manuals to see
what caveats they place on the use of the function.  Yea, I know that the two
runtimes aren't remotely the same but functions dealing with the underlying
file system must be close in nature as you're not going to be able to change
the behavior of the file system with a new runtime.

=====
Earnie Boyd <mailto:earnie_boyd AT yahoo DOT com>

Newbies, please visit
<http://www.freeyellow.com/members5/gw32/index.html>

(If you respond to the list, then please don't cc me)
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019