Conference turris::decc

You should also look at the hardware documentation for the
disk drive(s) she will be using.  Some disks guarantee to
complete the current 512-byte block if something goes wrong
(such as a power failure), while others don't.  I doubt if
any disks we support provide such a guarantee for larger
chunks.

I don't see anything obvious in the documentation, myself.  I'll ask one of the
RTL folks to respond.

						Brian

  I was not able to reproduce the problem. The cluster size of the device
  is 4, so in the example below I tried to write 5 blocks when only 4 blocks
  were available.

  I'm not sure, that fwrite() must fail if there is no room on the device
  because on [f]write() the data usually are copied to the internal CRTL
  buffer which is big enough to hold a number of 512-byte blocks. What fails
  is fflush(), fsync() or fclose() when an attempt is made to transfer the data
  from the buffer to the file.

  Boris

$ say f$getsy("version")
V6.1    
$ say f$getsy("hw_name")
VAXstation 4000-VLC
$ show dev sys$disk

Device                  Device           Error    Volume         Free  Trans Mnt
 Name                   Status           Count     Label        Blocks Count Cnt
$1$DKB106:    (xxxxxx)  Mounted              0  xxxxxxx              4     5  30
$ run x
fsync: no space left on device

$ dir junk.out

Directory DISK:[DIRECTORY]

JUNK.OUT;14                0/0        18-FEB-1997 23:12:23.72  (RWED,RWED,RWED,)

Total of 1 file, 0/0 blocks.

X.C
===
#include <stdio.h>
#include <stdlib.h>

main()
{
  FILE *fp;
  char buf[512*5];

  if ( (fp = fopen("junk.out","w")) == NULL ) {
    perror("fopen");
    exit(EXIT_FAILURE);
  }

  if ( fwrite(buf,sizeof(buf),1,fp) != 1 )
    perror("fwrite");
  else if ( fsync(fileno(fp)) )
    perror("fsync");

  exit(EXIT_SUCCESS);
}

   If the customer is worried about this stuff, I'd look at a combination
   of direct RMS calls and RMS Journaling -- with direct use of RMS, one
   has much better control over file allocation and file extensions, and
   rather better control over RMS processing errors.

   With C, you're looking to get a routine that emulates UNIX behaviour to
   do something very platform-specific...

   With RMS journaling, one gets a consistent view of files around processing
   errors, particularly around recovery from errors.

   I've since noted that .0 was cross-posted in the RMS notes conference,
   and that I had previously butchered the spelling of `journaling'...
   (This is a reposting.)