Return to BSD News archive
Xref: sserve comp.os.linux.development:2063 comp.os.386bsd.development:1327 comp.os.386bsd.misc:1288 Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!noc.near.net!news.delphi.com!news.delphi.com!not-for-mail From: cshaulis@news.delphi.com (CSHAULIS@DELPHI.COM) Newsgroups: comp.os.linux.development,comp.os.386bsd.development,comp.os.386bsd.misc Subject: Re: Has anyone written a Mac FS or Mac FS Access utilities for Linux or 386BSD? Date: 18 Oct 1993 23:02:56 -0400 Organization: General Videotex Corporation Lines: 24 Message-ID: <29vld0$n11@news.delphi.com> References: <CEv6Co.MA1.3@cs.cmu.edu> <29o4a1$r6u@u.cc.utah.edu> <29otpb$s8a@news.u.washington.edu> NNTP-Posting-Host: news.delphi.com tzs@stein3.u.washington.edu (Tim Smith) writes: >A Wizard of Earth C <terry@cs.weber.edu> wrote: >>Note that you will either have to extend the VNOPS tabe or forget about >>resource forks. >How about making each Mac file appear to be three unix files? Mac file >"foo" would appear under unix as "foo" (the data fork), "foo:r" (the >resource fork), and "foo:i" (the Finder information). >--Tim Smith I agree with Tim's idea. I've heard talk before about doing all sorts of crazy stuff to the Linux kernel to manage Mac resources and treat files like macs do, and so forth. I find the idea very distasteful. I'd vote for the file.r, file.d, file.i design -- that should be sufficient for grabbing fonts, text, and so forth. If ya need to pick apart the resource fork then someone could write a resource decompiler like the windows folks use, just don't stick it in the file system code. My two cents, Christopher cshaulis@Delphi.com