Path: utzoo!utgpu!watmath!att!dptg!rutgers!cs.utexas.edu!csd4.csd.uwm.edu!mailrus!ncar!tank!eecae!cps3xx!rang
From: rang@frith.egr.msu.edu (Anton Rang)
Newsgroups: comp.sys.mac.programmer
Subject: Re: System 7.0 (file system, file IDs, aliases)
Summary: File system changes are complicated
Keywords: file system aliases
Message-ID: <4374@cps3xx.UUCP>
Date: 30 Aug 89 17:29:01 GMT
References: <227700026@uxa.cso.uiuc.edu> <483@sunfs3.camex.uucp> <9173@thorin.cs.unc.edu> <13784@shamash.cdc.com> <490@sunfs3.camex.uucp> <8368@hoptoad.uucp> <3214@zeus.unl.edu> <1394@intercon.UUCP> <8381@hoptoad.uucp>
Sender: usenet@cps3xx.UUCP
Reply-To: rang@cpsvax.cps.msu.edu (Anton Rang)
Organization: Engineering, Michigan State University, E. Lansing
Lines: 53

In article <8381@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
  [ Stuff about file ID information deleted ]
>David Oster had a good point about the programming implications.  You
>now must save your documents by overwriting the old file.  Never mind
>that most people either delete the old file before creating a new one,

  If you do this, please remember to save the file comment ID (and the
other Finder information).  This is one of my pet peeves about a few
of the public-domain programs I have (most of the [few] commercial
ones seem to work OK).

>or write the new one while the old one is still around for an extra
>layer of failureproofing.

  Yes, this is a good idea.  An alternative is to copy the old file
somewhere else, then write the new file onto it, then delete the copy.
It's a little messy, though--I agree.

>  Never mind that overwriting the old file
>preserves fragmentation even when the disk is capable of laying out
>the file in a smarter fashion.

  This is only true if you don't truncate the file before overwriting
it.  A call to SetEOF to truncate the file to zero length, then a call
to Allocate to grab however much space you need, will let the file
system grab contiguous free space if it can.

>(And for anyone who may think that file ids are required for the new
>symbolic link feature, which *is* useful -- think again.  All you need
>to store is what UNIX stores, the full path name.)

  Umm, I really can't totally agree.  It is *possible* to implement
symbolic links by storing the full path name.  However, I don't like
it, because renaming files then breaks symbolic links.  (It can be
very frustrating to discover that a program doesn't run because it
uses a symbolic link and the target has been renamed or deleted.)
  It's a little better to use the directory ID and file name--that
way, renaming/moving the directory doesn't break the link.  Renaming
the file still does, though.  A file ID system would work best (kind
of like UNIX's hard links), but the HFS directory structure doesn't
allow lookups by file-ID (file IDs already exist, they're called file
numbers and are used internally by HFS).  Without a lookup mechanism,
file IDs are sort of useless.
  Of course, you can always find the file with the right ID by just
searching the whole HFS directory tree :-) .

>Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com


+----------------------------------+------------------------+
| Anton Rang (grad student)	   | "VMS Forever!"         |
| Michigan State University	   | rang@cpswh.cps.msu.edu |
+----------------------------------+------------------------+