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
From: Steve Jorgensen <steve AT khoral DOT com>
Message-Id: <199910211808.MAA02887@benson>
Subject: Re: Mmap problem
To: cygwin AT sourceware DOT cygnus DOT com
Date: Thu, 21 Oct 1999 12:08:53 -0600 (MDT)
In-Reply-To: <19991021105433.A4912@cygnus.com> from "Chris Faylor" at Oct 21, 99 10:54:33 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Chris Faylor wrote
>> On Thu, Oct 21, 1999 at 05:08:02AM -0700, Earnie Boyd wrote:
>> >--- 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.
>> 
>> There is a queue but it is applicable only to unlinking files.

	Well, I've gone as far as munmaping and closing the file,
	then reopening it and truncating that, but that doesn't
	work either.

						Steve

-- 
-----------------------------------------------------------
Steven Jorgensen      steve AT khoral DOT com	    steve AT haunt DOT com
------------------------------+----------------------------
Khoral Research Inc.          | PHONE: (505) 837-6500
6200 Uptown Blvd, Suite 200   | FAX:   (505) 881-3842
Albuquerque, NM 87110         | URL: http://www.khoral.com/
-----------------------------------------------------------

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