Path: csiph.com!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!feeds.phibee-telecom.net!usenet.ukfsn.org!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: A proposal to handle file encodings Date: Sat, 24 Nov 2012 15:51:59 +0000 (UTC) Organization: UK Free Software Network Lines: 24 Message-ID: References: <50aed080$0$292$14726298@news.sunsite.dk> NNTP-Posting-Host: 84.45.235.129 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: localhost.localdomain 1353772319 14898 84.45.235.129 (24 Nov 2012 15:51:59 GMT) X-Complaints-To: usenet@localhost.localdomain NNTP-Posting-Date: Sat, 24 Nov 2012 15:51:59 +0000 (UTC) User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2) Xref: csiph.com comp.lang.java.programmer:19896 On Thu, 22 Nov 2012 21:28:55 -0800, Roedy Green wrote: > > The bBase people got this right long ago. You don't go writing files > without a header describing the format of what was in the file. > IBM got it pretty much right in the OS/400 operating system. The metadata, which is held in the filing system catalogue, is transparently and permanently associated with the file. Its a general mechanism: the system provides standard metadata for source files, executables etc. and the developer creates the metadata for, e.g. fixed field data files with keyed access. The only demerit is that it uses a rather ugly two level filing system. The UNIX/Linux equivalent would be to keep the meta-data in the file's inode alongside the access permissions and to modify the file copy and move operations to silently handle the metadata by duplicating that part of the inode as and when needed. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |