On Tuesday, July 9, 2002, at 04:10 PM, Louis Demers wrote: At 12:27 -0400 2002.07.09, Jim Magee wrote: On Tuesday, July 9, 2002, at 12:32 AM, Louis Demers wrote: trying to port inn news server 2.3.3 to osx and the standard distribution seems to have problems with a mmap call. A static data is mmap to a file and then porperly written (I dumped all 130180 bytes to a file and it's ok) but when unmapped, the file reverts to all zeros. I checked and the file descriptor is opened with O_RDWR, the mmap is done with PROT_WRITE|PROT_READ. Did you set the MAP_SHARED flag? GROUPheader = mmap(0, 131080, flag, MAP_SHARED, GROUPfd, 0) and the file descriptor GROUPfd was opened O_RDWR | O_CREAT. How large was the file when you mapped it, Initially the file doesn't exist sot it is created with 0 bytes. and how much of it did you map? I imagine that the call to mmap mapped all 131080 and extended the file. mmap() does not extend a file. You have to use truncate()/ftruncate() or write()/pwrite() to extend the file. See <http://www.opengroup.org/onlinepubs/007904975/toc.htm> For SUSV3 spec for mmap() "If the size of the mapped file changes after the call to mmap() as a result of some other operation on the mapped file, the effect of references to portions of the mapped region that correspond to added or removed portions of the file is unspecified." "The system shall always zero-fill any partial page at the end of an object. Further, the system shall never write out any modified portions of the last page of an object which are beyond its end." "[ENXIO] Addresses in the range [off,off+len) are invalid for the object specified by fildes." So your mmap(0, 131080, flag, MAP_SHARED, GROUPfd, 0), should have failed for the 0 sized file. However it also allows the implementation to not treat the request as "invalid" provided that: "The mmap() function can be used to map a region of memory that is larger than the current size of the object. Memory access within the mapping but beyond the current end of the underlying objects may result in SIGBUS signals being sent to the process. The reason for this is that the size of the object can be manipulated by other processes and can change at any moment. The implementation should tell the application that a memory reference is outside the object where this can be detected; otherwise, written data may be lost and read data may not reflect actual data in the object." So your store to memory should have generated a SIGBUS.... [Please file a bug]. If you read further: "Note that references beyond the end of the object do not extend the object as the new end cannot be determined precisely by most virtual memory hardware. Instead, the size can be directly manipulated by ftruncate()." Hope this helps, --Umesh -- Umesh Vaishampayan Apple Computer, Inc. Mac OS X Kernel Ph: (408) 974 0229 _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.