HFS+

[nathan r. hruby]

On Thu, 19 Jun 2003, Christopher Murtagh wrote:

>  Having worked with Macs for more than 10 years, I can honestly say that I
> have seen more corrupted HFS[+] file systems than anything else. The
> journaling took a pretty serious performance hit (from Apple's own specs,
> which oftem means much worse in the real world). It also is a 'case
> insensitive, case preserving' (read 'worst of both worlds')  file system,
> and as you said 'things that no other file system have' (read:
> 'incompatible with everything') such as resource/data forks. IMO,
> resource/data forks, icon positioning, application association, etc. are
> things that should be handled at the application or operating system level
> and not the file system. For example, icon position is useless on a
> machine that is only used in console mode. Apple seems to agree with this
> as well, which is somewhat obvious in their .DS_Store, ._SomeFileName
> files and with the .app extension really being a folder (with data and
> resource items separated). I think that this is really a better move.
> 

Agreed, I just wish they'd quit sitting on the fence.  Maybe now that 
machines aren't booting os9 anymore, this will chnage in panther.

>  So, there you have it. This is why I think HFS+ should have died with 
> Classic.

Well, you do forget that there's a lot of apple stuff tuned to HFS+ 
(namely, Appletalk.. which is why SFP performance blows the doors off NFs 
performance).. there's a lot fo internals that need to deassume HFS, 
especially with 3rd party apps, many of which still require HFS specific 
metatdata and options.

-n

-- 
----------------------------------------
nathan hruby <nathan@drama.uga.edu>
computer services specialist  
uga drama & theatre                        
reality is a moving target
----------------------------------------