Path: csiph.com!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!feeds.phibee-telecom.net!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Dennis Lee Bieber <wlfraed@ix.netcom.com>
Subject: Re: How to safely maintain a status file
Date: Fri, 13 Jul 2012 13:29:22 -0400
Organization: > Bestiaria Support Staff <
References: <mailman.2034.1342096256.4697.python-list@python.org> <4ffecef4$0$6877$e4fe514c@news2.news.xs4all.nl> <4FFF0CB7.3030007@shopzeus.com> <mailman.2059.1342118365.4697.python-list@python.org> <fd846619-7de7-4c3b-8ed6-a14e9d55956e@p6g2000yqg.googlegroups.com> <mailman.2061.1342145524.4697.python-list@python.org> <4fff926b$0$29965$c3e8da3$5496439d@news.astraweb.com> <62e90523-a160-4e28-8109-9ce32d8952e1@googlegroups.com> <4fffcadc$0$29965$c3e8da3$5496439d@news.astraweb.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.2091.1342200621.4697.python-list@python.org>
Lines: 48
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:25276

On 13 Jul 2012 07:14:36 GMT, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> declaimed the following in
gmane.comp.python.general:

> 
> Open file objects do not necessarily correspond to files on disk. For 
> example, in standard Pascal, file objects are purely in-memory constructs 
> emulating files on a tape drive, with no relationship to on-disk files.
> 
> (Any half-decent Pascal compiler or interpreter will *also* give you ways 
> to access real files on disk, but that isn't covered by the standard.)
>
	Heck, in original Pascal, just reading from the console required
tricks (since Pascal I/O is defined with a 1 element look-ahead, and I/O
was opened at the start of execution). Mostly some internal flag to
delay console reads until the program actually accessed the buffer.

> a file name
> an inode (blocks on a disk)
> a file object
> 
> Of course it is useful to break the abstraction that file objects must be 
> files on disk. StringIO is one such example. Standard Pascal file objects 
> is another. Likewise, it is useful to be able to read from an inode that 
> is no longer connected to a file name.
>

	This does require a filesystem that uses "inode"s... Most computer
systems I've worked on didn't have that concept (they predated the POSIX
standard, and were not derived from UNIX).

	In the Amiga, the file name was stored in the file header block, not
in a directory block -- finding a file was done by hashing the file name
into an index in a directory block, and then following a linked list of
file header blocks until the desired name was found (and the file header
block contained pointers to the data blocks). {"Defragmenting" an Amiga
drive could get fun, as one not only moved data blocks around, but could
specify optimizations such as: position file header blocks immediately
before the file's data blocks [reducing head seeks when reading the
file] vs positioning file header blocks near their associated directory
block [reducing head seeks when reading file names]; reordering the
linked lists to put directory blocks ahead of file header blocks [making
directory navigation faster], etc.}

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/