creating file space via mmap

[David Robinson]

In article <3551 at kalliope.rice.edu>, auspex!guy at uunet.uu.net (Guy Harris) writes:
< Well, it depends on your definition of "better", but:
< 
< Users who pored over the 4.0 TRUNCATE(2) man page with a fine-toothed
< comb would have noticed that it says
< 
<    DESCRIPTION
< 	truncate() causes the file  referred  to  by  path  (or  for
< 	ftruncate()  the  object  referred  to by fd) to have a size
< 	equal to length bytes.  If the file  was  previously  longer
< 	than  length, the extra bytes are removed from the file.  If
< 								  ^^
< 	it was shorter, bytes between the old and  new  lengths  are
< 	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
< 	read  as  zeroes.  With ftruncate, the file must be open for
< 	^^^^^^^^^^^^^^^^
< 	writing.
< 
< The pre-4.0 TRUNCATE(2), and the 4.xBSD ones, didn't say anything about
< "(f)truncate" making files larger.  The reason why "(f)truncate" was,
< extended to allow you to, err, umm, *extend* the file (no pun intended)
< was to let you grow a file to which you were writing via "mmap" rather
< than via "write". 

This is a potential "gotcha" is if you are using NFS.  Many (currently most)
NFS servers, including SunOS 3.X, do not handle this correctly, SunOS 4.0
of course does.  These "broken" servers will not extend a file using
NFS_SETATTR() which is the SunOS 4.0 NFS equivilant of truncate().
Personally I think they should have implemented it as a write of a zero
byte for backwards bug compatibility.  This is the primary reason you
cannot run a 4.0 diskless client off a 3.X server.


-- 
	David Robinson		elroy!david at csvax.caltech.edu     ARPA
				david at elroy.jpl.nasa.gov	  ARPA
				{cit-vax,ames}!elroy!david	  UUCP
Disclaimer: No one listens to me anyway!