From owner-freebsd-hackers  Tue Jan 14 02:37:42 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id CAA05469
          for hackers-outgoing; Tue, 14 Jan 1997 02:37:42 -0800 (PST)
Received: from zwei.siemens.at (zwei.siemens.at [193.81.246.12])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id CAA05463
          for <hackers@FreeBSD.org>; Tue, 14 Jan 1997 02:37:33 -0800 (PST)
Received: from sol1.gud.siemens.co.at (root@[10.1.143.100]) by zwei.siemens.at (8.7.5/8.7.3) with SMTP id LAA00009 for <hackers@FreeBSD.org>; Tue, 14 Jan 1997 11:37:55 +0100 (MET)
Received: from ws2301.gud.siemens.co.at by sol1.gud.siemens.co.at with smtp
	(Smail3.1.28.1 #7 for <hackers@FreeBSD.org>) 
	id m0vk6Eh-00020RC; Tue, 14 Jan 97 11:36 MET
Received: by ws2301.gud.siemens.co.at (1.37.109.16/1.37)
	id AA263998091; Tue, 14 Jan 1997 11:34:51 +0100
From: "Hr.Ladavac" <lada@ws2301.gud.siemens.co.at>
Message-Id: <199701141034.AA263998091@ws2301.gud.siemens.co.at>
Subject: Re: truss, trace ??
To: avalon@coombs.anu.edu.au (Darren Reed)
Date: Tue, 14 Jan 1997 11:34:50 +0100 (MEZ)
Cc: terry@lambert.org, stesin@gu.net, karpen@ocean.campus.luth.se,
        hackers@FreeBSD.org
In-Reply-To: <199701140339.TAA00166@freefall.freebsd.org> from "Darren Reed" at Jan 14, 97 02:37:13 pm
X-Mailer: ELM [version 2.4 PL24 ME8a]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

E-mail message from Darren Reed contained:
> 
> The way I see it, there some things to consider which you may (or may
> not) want to `work' with cyclic files:
> 
> * offset - when you pass byte n of an n byte cylic file, should lseek tell
>            you that you're at byte n+1 or 0 ?
> 
>            Does it make sense to return n+1 if it can't lseek to that
>            absolute position ?  Would lseek() be hacked to goto position
>            x as x % n ?
> 
> 
> * blocks - why do you need to shuffle blocks around ?  Why not just just
>            the offset pointer once you get to the end ?  (In effect, the
>            write is done in 2 parts: first to the end of the file, the
>            second from the start).
> 
> * readers - if a reader is open and at position y and the next write will
>            go from x to x+n whre x+n > y does the writer block ? (Consider
>            that all data from y around to x is valid).

There is a rather simple way to satisfy most of these semantic requirements:
replace the leading blocks with holes--the file grows in the length, lseek
works as expected, but write is only guaranteed to succeed if it
fails in the last part of the file, and the filesystem occupancy does not
increase.  read succeeds always, but sometimes it returns a buffer full of 
(leading) zeros.

> 
> I guess you're thinking of what happens when you keep appending to a file
> ...(open - write - close.  I donm't  see that non-block sized record
> files can exist as cyclic files properly under Unix, eg:
> 
> I have a 30,000 byte cyclic file.  I write 1 byte to it, making 30,001.
> This isn't enough to delete the first block, but you must append it.
> (hmmm, would this mean the first block would be a fragment - would it even
> work ?)

Don't see a problem here; just blast away the leading blocks--unallocate them.
The last block can easily be a fragment.

/Marino
> 
> Anyone for O_CYCLIC ?
> 
> Darren
>