UFS vs HFS+, pros and cons?

Mark Conrad

unread,

Feb 23, 2003, 3:13:29 PM2/23/03

to

I am undecided as to whether to commit to UFS or HFS+.

Up until now, I have been favoring UFS, but am having second thoughts.

A whole bunch of "newly-designed" Mac applications just plain won't run
with UFS, even though they are "designed" to run native with OSX.

Are we stuck with the 'pacifier' of constantly needing to use the OS9
file system, even though Apple has went to OSX and Unix, which
supposedly is "better"?

Will we still be using the abandoned HFS+ in 10 to 20 years from now?

C'mon you UFS guys, give me some valid strong reasons for sticking with
UFS - - - or perhaps there are no reasons???

...preferably, reasons other than the case-sensitivity of UFS.

Mark-

Dave Pooser

unread,

Feb 23, 2003, 4:15:04 PM2/23/03

to

In article <230220031215211790%nos...@iam.invalid>, Mark Conrad
<nos...@iam.invalid> wrote:

> Are we stuck with the 'pacifier' of constantly needing to use the OS9
> file system, even though Apple has went to OSX and Unix, which
> supposedly is "better"?
>
> Will we still be using the abandoned HFS+ in 10 to 20 years from now?

HFS+ is far from abandoned. It's significantly faster than Apple's UFS
implementation, compatible with more software, and recommended by Apple
for everything except NFS shares. UFS is included primarily for
compatibility with legacy UNIX and Mac OS X Server 1.2 installations.
Swithc to HFS+ and don't look back.

--
Bubba Dave Pooser

A computer lets you make more mistakes faster than any invention in
human history with the possible exceptions of handguns and tequila.

Tacit

unread,

Feb 23, 2003, 4:38:04 PM2/23/03

to

>Are we stuck with the 'pacifier' of constantly needing to use the OS9
>file system, even though Apple has went to OSX and Unix, which
>supposedly is "better"?

Unix as an operating system may be "better," but that does not mean that the
old and much less sophisticated UFS file system is better than HFS.

HFS offers significant improvements over UFS, including better speed and
improved support for filesystem metadata. These were not factors in the dawn of
antiquity when UFS was first developed from the primordial ooze (at least in
computer terms); today, they are.

Unless you are running a file server in a primarily Unix environment, it's hard
to see any advantages to UFS.

--
"Quand la morale triomphe, il se passe des choses tres vilaines."
Literature. Art. Photography. Forums. Shareware. Kink. Sex.
All at: http://www.xeromag.com/franklin.html

Tom Harrington

unread,

Feb 23, 2003, 4:49:12 PM2/23/03

to

In article <230220031215211790%nos...@iam.invalid>,
Mark Conrad <nos...@iam.invalid> wrote:

> I am undecided as to whether to commit to UFS or HFS+.
>
> Up until now, I have been favoring UFS, but am having second thoughts.
>
> A whole bunch of "newly-designed" Mac applications just plain won't run
> with UFS, even though they are "designed" to run native with OSX.

Which ones, specifically? I've heard claims like this but don't know of
any applications that actually have this problem.

> Are we stuck with the 'pacifier' of constantly needing to use the OS9
> file system, even though Apple has went to OSX and Unix, which
> supposedly is "better"?
>
> Will we still be using the abandoned HFS+ in 10 to 20 years from now?

You're mistaken in calling HFS+ the "OS9" file system. Apple still
supports and recommends it for Mac OS X. It's far from abandoned.

> C'mon you UFS guys, give me some valid strong reasons for sticking with
> UFS - - - or perhaps there are no reasons???
>
> ...preferably, reasons other than the case-sensitivity of UFS.

I thought you were busily discovering these reasons-- like your use of
dd, for instance.

--
Tom "Tom" Harrington
Macaroni, Automated System Maintenance for Mac OS X.
Version 1.3: Now runs the Mac OS X "Repair Priviliges" Utility.
See http://www.atomicbird.com/

Howard S Shubs

unread,

Feb 23, 2003, 8:13:32 PM2/23/03

to

In article <230220031215211790%nos...@iam.invalid>,
Mark Conrad <nos...@iam.invalid> wrote:

> Will we still be using the abandoned HFS+ in 10 to 20 years from now?

Who ever implied that HFS+ was abandoned??

--
Today, on Paper-view: The World Origami Championship

Davoud

unread,

Feb 23, 2003, 8:54:20 PM2/23/03

to

Mark Conrad:

> I am undecided as to whether to commit to UFS or HFS+.

If you plan to use the Mac GUI, the answer is clearly HFS+.

> Up until now, I have been favoring UFS, but am having second thoughts.

As well you should.

> A whole bunch of "newly-designed" Mac applications just plain won't run
> with UFS, even though they are "designed" to run native with OSX.

That's about all you need to know.

> Are we stuck with the 'pacifier' of constantly needing to use the OS9
> file system, even though Apple has went to OSX and Unix, which
> supposedly is "better"?

Irrelevant. The file system is invisible to the average user.

> Will we still be using the abandoned HFS+ in 10 to 20 years from now?

If we are, it won't be "abandoned," will it?

> C'mon you UFS guys, give me some valid strong reasons for sticking with
> UFS - - - or perhaps there are no reasons???

There are no reasons unless you plan to use only the command line. If
that's the case, you spent a lot more money for your computer than was
necessary.

Davoud

--
david *at* davidillig *dawt* com

Jeremy

unread,

Feb 23, 2003, 9:07:50 PM2/23/03

to

Mark Conrad <nos...@iam.invalid> wrote:

> I am undecided as to whether to commit to UFS or HFS+.

There is no real reason to use UFS on OS X. If you have the odd Unix
software that needs case-sensitivity, or you want to run a webserver with
your own compile of Apache, make a UFS filesystem and mount it somewhere,
but leave the rest HFS+.

> Are we stuck with the 'pacifier' of constantly needing to use the OS9
> file system, even though Apple has went to OSX and Unix, which
> supposedly is "better"?

HFS+ is not the "OS 9" filesystem. Unix being "better" has nothing to
do with a choice between UFS and HFS+.

Apple's UFS implementation is significantly slower than HFS+. HFS+ has
a lot more metadata than UFS, and OS X takes advantage of it.

You seem to be under the unfortunate misimpression that UFS is Unix, or
vice-versa. This is far from the truth.

> Will we still be using the abandoned HFS+ in 10 to 20 years from now?

Who misled you into believing that HFS+ is abandoned? Apple doesn't even
recommend using UFS.

> C'mon you UFS guys, give me some valid strong reasons for sticking with
> UFS - - - or perhaps there are no reasons???

Correct.

> ...preferably, reasons other than the case-sensitivity of UFS.

That is the only advantage UFS has over HFS+ in OS X, at least currently.
So if you're looking for a reason to use UFS, I'm afraid you're stuck with
that one.

--
Jeremy | jer...@exit109.com

Mark Conrad

unread,

Feb 24, 2003, 9:59:35 AM2/24/03

to

In article <tph-2ED765.14491223022003@localhost>, Tom Harrington
<t...@pcisys.no.spam.dammit.net> wrote:

> > Up until now, I have been favoring UFS, but am having second thoughts.
> >
> > A whole bunch of "newly-designed" Mac applications just plain won't run
> > with UFS, even though they are "designed" to run native with OSX.
>
> Which ones, specifically? I've heard claims like this but don't know of
> any applications that actually have this problem.

Norton Tools - like Speed-Disk and Disk-Editor
...also Retrospect...
...also Symantec's ShrinkWrap...

I dunno for sure, but I suspect _any_ application that deals with
low-level stuff like the one's I mentioned above will not run properly
with UFS.

Dang, I hate to be put in the position of 'defending' UFS, because I
have my own doubts about using it.

> > C'mon you UFS guys, give me some valid strong reasons for sticking with
> > UFS - - - or perhaps there are no reasons???
> >
> > ...preferably, reasons other than the case-sensitivity of UFS.
>
> I thought you were busily discovering these reasons-- like your use of
> dd, for instance.

Well, yes and no. I was kinda forced into using dd because Symantec's
"ShrinkWrap" would not work with UFS.

> You're mistaken in calling HFS+ the "OS9" file system.

Granted, I should have wrote "...the file system Apple uses with their
OSs from 9.2.2 back through OS8 or thereabouts"

> Apple still supports and recommends it for Mac OS X.
> It's far from abandoned.

I thought one of the reasons Apple decided to use a Unix-based
operating system was to increase their market share by getting Unix
folks to use OSX.

Seems to me if I was a Unix guy, I would think twice about using OSX if
there was the roadblock of HFS+ to contend with. A lot of Unix app's
just plain won't run with HFS+.

Now let's look a the Big Picture for a moment.

We all know why Apple sticks with HFS+, with their weird system of
'resource-forks'.

It is because the "Apple Faithful" (like me for example) - would have
left in droves if there was a sudden switch to Unix-everything,
including switching to UFS.

None of my OS-8.6 applicactions would work, and I would be mad as a wet
hen that Apple made all my software instantly obsolete.

...so Apple decided to go through this big song and dance about
"recommending" that we all stick with using their weird file system
with it's 'resource-forks' - which no one else uses, not the Wintel
crowd, not the Unix people.

All those resource-forks do is to make it difficult to move files
between the Mac and other platforms.

As for the supposed speed difference in running UFS, it is Apple's
*implementation* of UFS that slows it down I suspect, not anything
characteristic about UFS itself - witness all the UFS-based servers
that ISPs use everyday, they run fast.

I think I have decided what to do, personally. I hate to do this,
because it is going to soak up a lot of my precious disk space.

Think I will run two seperate hard drives, one UFS, the other HFS+.
(running OSX on both drives, of course)

That way I can get the benefits of both file systems.

Heck, I might even run a third hard drive, with straight hard-core Unix
on it (no OSX) - just to get away from the Apple-imposed slowdown of
UFS.

Mark-

Mark Conrad

unread,

Feb 24, 2003, 10:22:43 AM2/24/03

to

In article <20030223163804...@mb-fk.aol.com>, Tacit
<tac...@aol.com> wrote:

> >Are we stuck with the 'pacifier' of constantly needing to use the OS9
> >file system, even though Apple has went to OSX and Unix, which
> >supposedly is "better"?
>
> Unix as an operating system may be "better," but that does not mean that the
> old and much less sophisticated UFS file system is better than HFS.

Aw c'mon, that doesn't make sense. The Unix guys in this NG claim that
the Unix OS is being continually improved, is much more secure and much
less crash-prone than Apple's "modern" OS-9.2.2 for example.

It just doesn't make sense that the Unix guys would 'forget' about
improving their UFS (file system) in step with the improvements to the
Unix OS.

Naturally, when Apple favors their HFS+ in OSX, it is going to make UFS
_appear_ to run slower.

If Apple had went-with UFS, they would be yapping about how much faster
UFS was running on OSX.

...but you and I know they could not go with UFS, without alienating
Apple users, so they had to use HFS+.

Mark-

Jerry Kindall

unread,

Feb 24, 2003, 12:37:04 PM2/24/03

to

In article <240220030726025806%nos...@iam.invalid>, Mark Conrad
<nos...@iam.invalid> wrote:

> In article <20030223163804...@mb-fk.aol.com>, Tacit
> <tac...@aol.com> wrote:
>
> > >Are we stuck with the 'pacifier' of constantly needing to use the OS9
> > >file system, even though Apple has went to OSX and Unix, which
> > >supposedly is "better"?
> >
> > Unix as an operating system may be "better," but that does not mean that the
> > old and much less sophisticated UFS file system is better than HFS.
>
> Aw c'mon, that doesn't make sense. The Unix guys in this NG claim that
> the Unix OS is being continually improved, is much more secure and much
> less crash-prone than Apple's "modern" OS-9.2.2 for example.
>
> It just doesn't make sense that the Unix guys would 'forget' about
> improving their UFS (file system) in step with the improvements to the
> Unix OS.

Well, it's true that there are file systems for UNIX with more support
for the kinds of things HFS+ supports. But they aren't UFS, they are
completely new file systems. And if you're a typical Mac user, none of
these "new" file systems have any compelling advantage over HFS+. So
if you're going to make your UNIX support another file system besides
UFS, there's no reason it shouldn't be HFS+.

--
Jerry Kindall, Seattle, WA
http://www.jerrykindall.com/

Jeremy

unread,

Feb 24, 2003, 1:24:31 PM2/24/03

to

Mark Conrad <nos...@iam.invalid> wrote:

> Aw c'mon, that doesn't make sense. The Unix guys in this NG claim that
> the Unix OS is being continually improved, is much more secure and much
> less crash-prone than Apple's "modern" OS-9.2.2 for example.
>
> It just doesn't make sense that the Unix guys would 'forget' about
> improving their UFS (file system) in step with the improvements to the
> Unix OS.

What is it that you think UFS has to do with Unix, exactly? Do you
think the two are inseperable? UFS isn't used on all Unix systems.

> Naturally, when Apple favors their HFS+ in OSX, it is going to make UFS
> _appear_ to run slower.

No, UFS *does* run slower, on OS X. It's not an illusion; the UFS
implementation is slower than the HFS+ implementation.

> If Apple had went-with UFS, they would be yapping about how much faster
> UFS was running on OSX.

If they'd made it faster, sure, I suppose they would have, but it's kind
of silly to wonder about that, because they didn't. So unless you want
to use UFS on sheer principle, I don't see what you're getting at.

> ...but you and I know they could not go with UFS, without alienating
> Apple users, so they had to use HFS+.

Or, maybe they couldn't think of a good reason to go with UFS either.
You certainly haven't presented any.

--
Jeremy | jer...@exit109.com

Jeremy

unread,

Feb 24, 2003, 1:34:06 PM2/24/03

to

Mark Conrad <nos...@iam.invalid> wrote:

> Seems to me if I was a Unix guy, I would think twice about using OSX if
> there was the roadblock of HFS+ to contend with.

But you're not a Unix guy, so you shouldn't assume what Unix guys would
say. For starters, why do you think HFS+ would be a "roadblock"? Why
do you think us Unix guys are going to care so much about a particular
filesystem that we wouldn't be willing to consider using a different one?

> A lot of Unix app's just plain won't run with HFS+.

Like what? I'm not using any UFS filesystems on my OS X machines, and I
have yet to encounter this problem.

There are only two issues I can think of, and neither of them results in
an application "just plain not running":

1. If you install Perl into /usr, which is a big newbie mistake anyway,
the LWP module's "HEAD" command will overwrite the system's "head" command.
Big deal; installing stuff into /usr is asking for trouble.

2. If you compile your own Apache instead of using Apple's, running it on
HFS+ will create security holes due to the case-insensitivity of the
filesystem.

I'd like to hear about all these Unix applications you've seen refuse to
run on HFS+. It would be quite a revelation.

> We all know why Apple sticks with HFS+, with their weird system of
> 'resource-forks'.
>
> It is because the "Apple Faithful" (like me for example) - would have
> left in droves if there was a sudden switch to Unix-everything,
> including switching to UFS.

No, it's probably because they're good at it, and it has features which
UFS lacks, like all that extra metadata. Not to mention resource forks,
which are good for backwards compatibility.

> As for the supposed speed difference in running UFS, it is Apple's
> *implementation* of UFS that slows it down I suspect, not anything
> characteristic about UFS itself - witness all the UFS-based servers
> that ISPs use everyday, they run fast.

This is true. However, unless you want to use UFS strictly for religious
reasons, it doesn't matter *why* it's slower. It's slower, and offers no
advantages over HFS+ other than case-sensitivity, so why use it?

> Think I will run two seperate hard drives, one UFS, the other HFS+.
> (running OSX on both drives, of course)
>
> That way I can get the benefits of both file systems.

Which are the benefits of UFS that you plan to enjoy?

--
Jeremy | jer...@exit109.com

Eric Albert

unread,

Feb 24, 2003, 1:37:02 PM2/24/03

to

In article <240220030702582311%nos...@iam.invalid>,
Mark Conrad <nos...@iam.invalid> wrote:

> We all know why Apple sticks with HFS+, with their weird system of
> 'resource-forks'.

Resource forks work on both HFS+ and UFS.

> None of my OS-8.6 applicactions would work

Classic works on UFS as far as I know.

> ...so Apple decided to go through this big song and dance about
> "recommending" that we all stick with using their weird file system
> with it's 'resource-forks' - which no one else uses, not the Wintel
> crowd, not the Unix people.

NTFS supports multiple-forked files, including resource forks.

-Eric

unread,

Feb 24, 2003, 6:58:08 PM2/24/03

to

In article <b3e8ov$8gq$2...@pcls4.std.com>, Tony Lawrence
<a...@shell01.TheWorld.com> wrote:

> Joe Davison <hal...@attbi.com> wrote:
>
> : Having used/programmed unix systems for 30 years, I'm comfortable with
> : mixed case file names, but I've learned to live with single case -- some
> : programming languages do the same thing, and many other OS's do, too.
> : Fact is, many non-programmers don't remember whether they used a capital
> : letter for the first name of a file or not -- and don't want to
> : remember. Apple has always figured it was better to meet the needs of
> : "the rest of us" than the needs of programmers, who are more flexible.
> : I think they're right!
>
> I've "only" been doing Unix for a little more than 20 years, but I generally
> don't mind mixed case, except that it annoys me that I cannot "cd doc*" to
> get to Documents. If case is not supposed to matter, it shouldn't ever
> matter.

The problem here is that the shell thinks case matters, even though it
doesn't.

Jeremy

unread,

Feb 24, 2003, 8:02:49 PM2/24/03

to

Tony Lawrence <a...@shell01.TheWorld.com> wrote:

> I've "only" been doing Unix for a little more than 20 years, but I generally
> don't mind mixed case, except that it annoys me that I cannot "cd doc*" to
> get to Documents. If case is not supposed to matter, it shouldn't ever
> matter.

That's case mattering to the shell, not to the OS or the filesystem.

I've got zsh's completion set up to be case-insensitive, so although "cd doc*"
doesn't work, "cd doc<tab>" results in "cd Documents". I have no idea how to
accomplish that in tcsh, but something like this should do in zsh:

zstyle ':completion:*' matcher-list 'm:{a-z}={A-Z}'

There may even be a way to make the globbing be case-insensitive, but I don't
know how.

--
Jeremy | jer...@exit109.com

Tony Lawrence

unread,

Feb 25, 2003, 7:34:42 AM2/25/03

to

Jeremy <jer...@exit109.com> wrote:
: Tony Lawrence <a...@shell01.TheWorld.com> wrote:

:> I've "only" been doing Unix for a little more than 20 years, but I generally
:> don't mind mixed case, except that it annoys me that I cannot "cd doc*" to
:> get to Documents. If case is not supposed to matter, it shouldn't ever
:> matter.

: That's case mattering to the shell, not to the OS or the filesystem.

Yes, I understand. But again: if case isn't supposed to matter, it shouldn't
ever matter. The argument was made that case insensitivity is a benefit
to the Unix illiterate; if that's the goal then the shell should
complete the job.

But it's hardly a big deal: I screw up a couple of times a week - I
can live with it.

st...@temple.edu

unread,

Feb 25, 2003, 10:45:19 AM2/25/03

to

Mark Conrad <nos...@iam.invalid> wrote:

> I am undecided as to whether to commit to UFS or HFS+.

> Up until now, I have been favoring UFS, but am having second thoughts.

> A whole bunch of "newly-designed" Mac applications just plain won't run
> with UFS, even though they are "designed" to run native with OSX.

Which file system is better depends to some extent on your needs. For most
people, HFS+ is the way to go. The only reason I can see to run UFS is for
serving out certain types of web content. Apple also recommends HFS+ for
the OS volume, and most Mac application developers assume you're using
HFS+. I really see no reason for the typical user to use UFS.

Dragonmaster Lou

unread,

Feb 25, 2003, 11:12:11 AM2/25/03

to

In article <240220030937040775%jerryk...@nospam.invalid>, Jerry
Kindall wrote:

> Well, it's true that there are file systems for UNIX with more support
> for the kinds of things HFS+ supports. But they aren't UFS, they are
> completely new file systems. And if you're a typical Mac user, none of
> these "new" file systems have any compelling advantage over HFS+. So
> if you're going to make your UNIX support another file system besides
> UFS, there's no reason it shouldn't be HFS+.

Actually, that's not entirely the case. A lot of UNIX file systems
don't require defragging (or at least don't require defragging until
they're over 90% full anyway), and last I checked HFS+ does require
defragging. That would be a nice feature in any file system.

--

-------------------- http://www.techhouse.org/lou ----------------------
"Dragonmaster Lou" | "Searching for a distant star, heading off to
lou at techhouse org | Iscandar, leaving all we love behind, who knows
Tech House Alum | what dangers we'll find..."
-----------------------------------------------------------------------

Jerry Kindall

unread,

Feb 25, 2003, 1:30:04 PM2/25/03

to

In article <slrnb5n5f...@techhouse.brown.edu>, Dragonmaster Lou
<l...@SPAM.ME.AND.DIE.techhouse.org> wrote:

> In article <240220030937040775%jerryk...@nospam.invalid>, Jerry
> Kindall wrote:
>
> > Well, it's true that there are file systems for UNIX with more support
> > for the kinds of things HFS+ supports. But they aren't UFS, they are
> > completely new file systems. And if you're a typical Mac user, none of
> > these "new" file systems have any compelling advantage over HFS+. So
> > if you're going to make your UNIX support another file system besides
> > UFS, there's no reason it shouldn't be HFS+.
>
> Actually, that's not entirely the case. A lot of UNIX file systems
> don't require defragging (or at least don't require defragging until
> they're over 90% full anyway), and last I checked HFS+ does require
> defragging. That would be a nice feature in any file system.

HFS+ doesn't _require_ defragging; a volume with fragments works fine.
If a volume is badly fragmented, defragging can sometimes marginally
improve performance, but for most applications this isn't important.

Fragmentation is inevitable on any file system that allows files to
grow. I suppose one could get around this by moving the entire file to
contiguous free space whenever it needed more room to grow, but there's
no reason HFS+ couldn't do that too, if Apple decided it'd be of
benefit. The performance decreases caused by fragmentation on modern
hardware are generally minor, though.

Jeremy

unread,

Feb 25, 2003, 2:51:17 PM2/25/03

to

Tony Lawrence <a...@shell01.TheWorld.com> wrote:

>> That's case mattering to the shell, not to the OS or the filesystem.
>
> Yes, I understand. But again: if case isn't supposed to matter, it shouldn't
> ever matter. The argument was made that case insensitivity is a benefit
> to the Unix illiterate; if that's the goal then the shell should
> complete the job.

This ideal would require modification of nearly every Unix command-line
tool (and, more importantly, the system libraries). Let's get Apple to
modify them to understand resource forks and HFS+ metadata before we worry
about this. :)

--
Jeremy | jer...@exit109.com

Mark Conrad

unread,

Feb 25, 2003, 4:11:07 PM2/25/03

to

In article <10461110...@ok-corral.gunslinger.net>, Jeremy
<jer...@exit109.com> wrote:

> What is it that you think UFS has to do with Unix, exactly?
> Do you think the two are inseperable?

Uh, the name, "Unix File System" (UFS)

In a way, the file system and Unix _are_ inseperable, such that when
I pick a file system I am stuck with it, warts and all. If I suddenly
decide I want the features of a different file system, I hafta set
aside another partition for Unix in order to use the 'other' file
system. This can take a prohibative amount of disk space.

> No, UFS *does* run slower, on OS X. It's not an illusion...

Okay, bad choice of words on my part. What I meant to say was that
there is nothing intrinsic about UFS that makes it run slower, it is
merely Apple's implementation of UFS that makes it run slower with OSX.

With a straight Unix box, UFS no doubt runs very fast, otherwise the
Unix guys would junk it and run HFS+ instead.

> > ...but you and I know they could not go with UFS, without alienating
> > Apple users, so they had to use HFS+.
>
> Or, maybe they couldn't think of a good reason to go with UFS either.
> You certainly haven't presented any.

Oh, I think being able to load the thousands of Unix free applications
out there into UFS with better assurance they will run okay is a good
reason for wishing Apple would have jumped the other way.

Well you know what they say, wish in one hand and pee in the other
hand, and see which one will get full faster.

I gotta face the fact that Apple already made their choice, and work
with what I have available.

According to statements made by some book authors, Apple is 'waffling'
a little by encouraging developers not to rely on HFS+ resource forks,
but rather to encapsulate the resource forks into "packages" so they
will run on UFS. To me that sounds like Apple might have plans to
abandon HFS+ in the future.

A good reason for abandoning HFS+ would be to make OSX more
cross-platform friendly, to increase Apple's market share.

Mark-

Mark Conrad

unread,

Feb 25, 2003, 4:11:16 PM2/25/03

to

In article <ejalbert-D3D066...@news.stanford.edu>, Eric
Albert <ejal...@stanford.edu> wrote:

> Resource forks work on both HFS+ and UFS.

- - - and - - -

> Classic works on UFS as far as I know.

Sorry, I should have explained further what I meant.

I meant "straight" UFS, without the cop-out of "loading OS9 drivers".

So far as I know (correct me if I am wrong) - when I "create a UFS disk
drive" and then mess everything up by "loading OS9 drivers" - - - well
then it is almost the same as if I had never created a UFS hard drive
in the first place, because the blasted OS9 drivers are in place,
almost the same as if I had created a HFS+ hard drive in the first
place, with both UFS and HFS+ partitions on the same hard drive.

Actually, in the case mentioned above, I think a "combination" file
system is created, part UFS, part HFS+. Classic will run, but any
application that needs "pure" HFS+ will not run, like for example
Symantec's "ShrinkWrap", or Norton's "Disk Editor+", or Norton's
"SpeedDisk".

By contrast, with a *straight* UFS type of filesystem, any OS9
partitions or hard drives are not even visible on the desktop, so
classic can't possibly work, and Apple resource forks will not be
recognized, which everyone knows when it comes to "straight" UFS.

Correct me if I am wrong about any of the above statements, I am
playing all of this by ear.

Mark-

Mark Conrad

unread,

Feb 25, 2003, 4:11:27 PM2/25/03

to

In article <10461116...@ok-corral.gunslinger.net>, Jeremy
<jer...@exit109.com> wrote:

> It's slower, and offers no advantages over HFS+
> other than case-sensitivity, so why use it?

First, a disclaimer. I am still trying to decide whether to use HFS+,
or UFS, or both of them.

I am kinda leaning towards using both, on the same computer.

> It's slower...

Not on a straight Unix box. Don't blame UFS for running slow, blame
Apple's implementation of UFS.

No argument about UFS running slower on OSX, but that does not bother
me because I don't use any file-system-extensive applications anyhow.

About UFS -
> ...so why use it?

Oh I dunno, because it is there ;-)

> Which are the benefits of UFS that you plan to enjoy?

I have some hazy notion of perhaps trying to download some straight
Unix software in the distant future, which no doubt would be more
likely to run if I put it in a UFS partition.

Mark-

Mark Conrad

unread,

Feb 25, 2003, 4:11:36 PM2/25/03

to

In article <b3g32f$l4a$3...@cronkite.temple.edu>, <st...@temple.edu> wrote:

> I really see no reason for the typical user to use UFS.

I question whether there is any such thing as a typical user.

A naive, uninformed, unimaginative point-and-click user, perhaps.

Why should we even care what a "typical user" does. Every one of us is
different, and we all use our computers in a different fashion.

I am not going to degrade my choices to the lowest common denominator
"typical-user".

I wanna use my computer to teach virtual classrooms of 10,000 students.

I wanna do brain surgery remotely, controlling a robotic "surgeon"
mechanism on Mars, which does the actual surgery.

I wanna create a hybrid human, part silicon, part human, perhaps with a
silicon chip implanted in his brain to provide him with a photographic
memory - silicon additions to his eyes to let him see infra-red,
ultra-violet.

I wanna create computer software that learns by itself, instead of
needing a programmer to tell it what to do every-step-of-the-way.

Heck, why stop there, I am letting my brain become constipated by
listening to the unimaginative dribble in this NG.

Why nut just download *everything* from a person's brain after they
are 70 years or so old, and finally have all their smarts.

...and then, and then, reload all these priceless life experiences
gained in a lifetime of hard knocks into the silicon "brain" of a
humanoid robot, such that his life continues for another 80 years with
his same original brain and emotions - - - only this time he is already
'born-smart' and knows to invest his money into VHS instead of BETA,
and buy his own south-sea island paradise instead of wasting his money
on educating his ingrate offspring, in the vain hope that they will
make something of their lives.

Mark-

Tacit

unread,

Feb 25, 2003, 4:58:41 PM2/25/03

to

>So far as I know (correct me if I am wrong) - when I "create a UFS disk
>drive" and then mess everything up by "loading OS9 drivers" - - - well
>then it is almost the same as if I had never created a UFS hard drive
>in the first place, because the blasted OS9 drivers are in place,
>almost the same as if I had created a HFS+ hard drive in the first
>place, with both UFS and HFS+ partitions on the same hard drive.

No.

The OS 9 drivers have nothing, NOTHING to do with the filesystem. They live on
the hard disk outside filesystem space (in the Apple driver partition).
Installing OS 9 drivers does not in any way change the filesystem on the drive.

>Actually, in the case mentioned above, I think a "combination" file
>system is created, part UFS, part HFS+. Classic will run, but any
>application that needs "pure" HFS+ will not run, like for example
>Symantec's "ShrinkWrap", or Norton's "Disk Editor+", or Norton's
>"SpeedDisk".

Applications like Disk Doctor and Speed Disk are HFS disk utilities.There is no
reason to run an HFS disk utility on a UFS file system. *Of course* HFS disk
utilities require an HFS file system! The disk utility's purpose in life is to
fix directory errors on...er, HFS disks.

>By contrast, with a *straight* UFS type of filesystem, any OS9
>partitions or hard drives are not even visible on the desktop, so
>classic can't possibly work, and Apple resource forks will not be
>recognized, which everyone knows when it comes to "straight" UFS.

Whether or not a filesystem can be mountede in OS 9 depends on two separate,
distinct things:

1. If the disk has an OS 9 driver;
2. If the disk has a filesystem that OS 9 knows about and can mount.

Don't confuse these two things. They are entirely unrelated.

Jeremy

unread,

Feb 25, 2003, 5:27:48 PM2/25/03

to

Mark Conrad <nos...@iam.invalid> wrote:

>> What is it that you think UFS has to do with Unix, exactly?
>> Do you think the two are inseperable?
>
> Uh, the name, "Unix File System" (UFS)

Except that UFS stands for "Unified File System".

UFS is not used by all Unix systems other than OS X, you know.

>> No, UFS *does* run slower, on OS X. It's not an illusion...
>
> Okay, bad choice of words on my part. What I meant to say was that
> there is nothing intrinsic about UFS that makes it run slower, it is
> merely Apple's implementation of UFS that makes it run slower with OSX.

But this has nothing to do with your question. UFS is slower on OS X, so
whether to use it on OS X has absolutely nothing to do with whether UFS
might be faster on some other operating system.

>> Or, maybe they couldn't think of a good reason to go with UFS either.
>> You certainly haven't presented any.
>
> Oh, I think being able to load the thousands of Unix free applications
> out there into UFS with better assurance they will run okay is a good
> reason for wishing Apple would have jumped the other way.

Except that you can do that with HFS+.

--
Jeremy | jer...@exit109.com

Jeremy

unread,

Feb 25, 2003, 5:31:25 PM2/25/03

to

Mark Conrad <nos...@iam.invalid> wrote:

>> It's slower...
>
> Not on a straight Unix box. Don't blame UFS for running slow, blame
> Apple's implementation of UFS.

You can't possibly be thinking that it's a good idea to us UFS on OS X
because UFS is fast on some other versions of Unix? That doesn't even
make sense.

>> Which are the benefits of UFS that you plan to enjoy?
>
> I have some hazy notion of perhaps trying to download some straight
> Unix software in the distant future, which no doubt would be more
> likely to run if I put it in a UFS partition.

I have already downloaded and compiled a great deal of "straight Unix
software" and I use it on a daily basis, including the newsreader I'm
using to post this. It all runs just fine on HFS+. Someone seems to
have put the idea into your head that you'll need UFS to run regular
Unix software, but that is simply *not* true, not even remotely.

--
Jeremy | jer...@exit109.com

Tony Lawrence

unread,

Feb 25, 2003, 7:07:36 PM2/25/03

to

Jeremy <jer...@exit109.com> wrote:
: Tony Lawrence <a...@shell01.TheWorld.com> wrote:

:>> That's case mattering to the shell, not to the OS or the filesystem.
:>
:> Yes, I understand. But again: if case isn't supposed to matter, it shouldn't
:> ever matter. The argument was made that case insensitivity is a benefit
:> to the Unix illiterate; if that's the goal then the shell should
:> complete the job.

: This ideal would require modification of nearly every Unix command-line
: tool (and, more importantly, the system libraries). Let's get Apple to

Nonsense. With a very few exceptions (find and grep being the only two I
can even think of immediately) no Unix commands can process wildcards at all -
that's the job of the shell, which passes the expanded arguments to the command.

Tom Harrington

unread,

Feb 25, 2003, 7:31:00 PM2/25/03

to

In article <250220031313145008%nos...@iam.invalid>,
Mark Conrad <nos...@iam.invalid> wrote:

> > It's slower...
>
> Not on a straight Unix box. Don't blame UFS for running slow, blame
> Apple's implementation of UFS.

Err... so what? If you're using a Mac, then it's the speed on the Mac
that matters.

Tom Harrington

unread,

Feb 25, 2003, 7:33:49 PM2/25/03

to

In article <250220031312443197%nos...@iam.invalid>,
Mark Conrad <nos...@iam.invalid> wrote:

> A good reason for abandoning HFS+ would be to make OSX more
> cross-platform friendly, to increase Apple's market share.

I bet that the number of users who would demand UFS over HFS+ is not big
enough to affect Apple's marketing plans.

Jeremy

unread,

Feb 25, 2003, 7:41:44 PM2/25/03

to

Tony Lawrence <a...@shell01.TheWorld.com> wrote:

>> This ideal would require modification of nearly every Unix command-line
>> tool (and, more importantly, the system libraries). Let's get Apple to
>
> Nonsense. With a very few exceptions (find and grep being the only two I
> can even think of immediately) no Unix commands can process wildcards at all -
> that's the job of the shell, which passes the expanded arguments to the command.

It's not just about expanding wildcards -- which grep doesn't do, as it uses
regular expressions. It's about accessing files. If all you care about is
wildcards, you can modify the shells and the glob() library function, but
then, you'd still have a situation where case matters sometimes.

See, you can't just change the stuff so that everything is case-insensitive,
because it's only HFS+ which is case-insensitive. If you're running a Unix
command line tool and looking at files on some other type of filesystem, like
UFS or NFS, then things need to be case-sensitive. They only need to be
case-insensitive when operating on case-insensitive filesystems. You may or
may not be able to rely on the filesystem itself to take care of everything
that needs to be taken care of, but my guess is that you can't.

--
Jeremy | jer...@exit109.com

Tony Lawrence

unread,

Feb 25, 2003, 8:01:49 PM2/25/03

to

Jeremy <jer...@exit109.com> wrote:
: Tony Lawrence <a...@shell01.TheWorld.com> wrote:

:>> This ideal would require modification of nearly every Unix command-line
:>> tool (and, more importantly, the system libraries). Let's get Apple to
:>
:> Nonsense. With a very few exceptions (find and grep being the only two I
:> can even think of immediately) no Unix commands can process wildcards at all -
:> that's the job of the shell, which passes the expanded arguments to the command.

: It's not just about expanding wildcards -- which grep doesn't do, as it uses
: regular expressions. It's about accessing files. If all you care about is
: wildcards, you can modify the shells and the glob() library function, but
: then, you'd still have a situation where case matters sometimes.

Yes, it IS just about expanding wildcards - where do you think the programs
get filenames from? As I said, only "find" takes raw wildcards for
filenames that I can think of.. yes, you are right about grep.

: See, you can't just change the stuff so that everything is case-insensitive,

: because it's only HFS+ which is case-insensitive. If you're running a Unix

Lordy. You think a shell couldn't tell what sort of filesystem it was
being asked to expand filenames upon?

Look, I'm not talking about simplistic stty stuff here: I'm saying that
if you are going to have filesystems like this, you need shells that
understand them. The shell needs to be aware of HOW it should
expand doc* on HFS+ and it currently is not.

Jim Glidewell

unread,

Feb 25, 2003, 10:15:42 PM2/25/03

to

In article <250220031313255660%nos...@iam.invalid>, Mark Conrad
<nos...@iam.invalid> wrote:

In article <b3g32f$l4a$3...@cronkite.temple.edu>, <st...@temple.edu> wrote:

>> I really see no reason for the typical user to use UFS.

> I question whether there is any such thing as a typical user.

> A naive, uninformed, unimaginative point-and-click user, perhaps.

As opposed to the pompous fool user...

> Why should we even care what a "typical user" does. Every one of us is
> different, and we all use our computers in a different fashion.

Lots of us aren't nearly as "special" as you are.

> I am not going to degrade my choices to the lowest common denominator
> "typical-user".

Your arrogance and elitism are showing. I have far more respect for the
average point-n-clicker than I have for you. And lots of people who
are better informed and more intelligent than you have looked at the
issue and found that the minor limitations of HFS+ are not a barrier
to productive work. *Whatever* one wants to do with a Mac.

The "lowest common denominator" user apparently has a lot more sense
than you display.

> I wanna use my computer to teach virtual classrooms of 10,000 students.

Except nobody's buying. And quite honestly, I have a hard time imagining
a worse teacher than you. Your constant over-estimation of your own
knowledge and intelligence, your inability to grasp new concepts,
and your pompous and imperious style all would seem to work against
any useful education taking place. With 10 students or 10,000...

> I wanna do brain surgery remotely, controlling a robotic "surgeon"
> mechanism on Mars, which does the actual surgery.

Use HFS+. It's optimized for that sort of thing. Case insensitivity
can be helpful when doing robotic surgery. You don't have to remember
whether it is "suture", "SUTURE", or "Suture"...

> I wanna create a hybrid human, part silicon, part human, perhaps with a
> silicon chip implanted in his brain to provide him with a photographic
> memory - silicon additions to his eyes to let him see infra-red,
> ultra-violet.

Grow up. And use HFS+, as it is the superior solution for cyborg-
resident file systems.

> I wanna create computer software that learns by itself, instead of
> needing a programmer to tell it what to do every-step-of-the-way.

You've had years to develop this using Lisp - what do you have to
show for it? Nothing, it appears. And the reason for this pathetic
state of A.I. affairs is... HFS+ ?!?

It's a poor carpenter who blames his tools.

> Heck, why stop there, I am letting my brain become constipated by
> listening to the unimaginative dribble in this NG.

I think that your cranial problems are due to biological, rather than
Usenet, reasons. But just to be sure, perhaps it is in your best interest
to avoid usenet altogether. You'll be missed, I'm sure...

I do find it interesting that you perceive others as being in a rut,
while your own fixation wrt OS9 partitions borders on OCD, IMHO.

Feel free to leave us to our "unimaginative dribble", oh dribbler
extraordinaire. We really don't _deserve_ your presence here...

> Why nut just download *everything* from a person's brain after they
> are 70 years or so old, and finally have all their smarts.

Why "nut" indeed?

Too late for you, I'm afraid. Whatever smarts were once there appear to
already be in a serious state of decay.

> ...and then, and then, reload all these priceless life experiences
> gained in a lifetime of hard knocks into the silicon "brain" of a
> humanoid robot, such that his life continues for another 80 years with
> his same original brain and emotions - - - only this time he is already
> 'born-smart' and knows to invest his money into VHS instead of BETA,
> and buy his own south-sea island paradise instead of wasting his money
> on educating his ingrate offspring, in the vain hope that they will
> make something of their lives.

I can't imagine a worse world than one populated with senile robotic
windbags, muttering about their stupid ingrate offspring. Are you
referring to your *own* children, BTW? I'm sure they'd be touched...

What a pompous, idiotic bunch of drivel. When you exhaust any reasonable
arguments why one should use UFS, you start in with the "visionary" B.S.
Nobody buys this dreck - you are completely transparent. Once again you
start an ostensibly technical thread, then go into rant mode when folks
fail to defer to your "superior" knowledge, wisdom, and vision. And for
those few who might be fooled by your sad parody of an English don, I am
more than happy to point out the foolishness explicitly.

If you think that *anyone* is impressed, I'm afraid you're only fooling
yourself. Perhaps, in days past, you could ramble mindlessly on without
anyone calling you on it. Too bad those days are gone.

Welcome to Usenet.

Jeremy

unread,

Feb 25, 2003, 11:45:39 PM2/25/03

to

Tony Lawrence <a...@shell01.TheWorld.com> wrote:

> Yes, it IS just about expanding wildcards - where do you think the programs
> get filenames from?

They can also come from the user, or anywhere else.

Like I said, if all you're interested in is globbing, then sure, that would
just mean modifying all the shells, a couple of library functions, and a
few command line tools. Beyond that, you could just count on the filesystem
to take care of the rest, but I don't think that would be quite enough.

> As I said, only "find" takes raw wildcards for filenames that I can think
> of.. yes, you are right about grep.

Well, I believe pax does, and Perl does internal globbing now too (it used
to fork a csh to do it).

--
Jeremy | jer...@exit109.com

Eric Albert

unread,

Feb 26, 2003, 1:37:31 AM2/26/03

to

In article <250220031312443197%nos...@iam.invalid>,
Mark Conrad <nos...@iam.invalid> wrote:

> According to statements made by some book authors

Which book authors? I'm quite curious.

> Apple is 'waffling'
> a little by encouraging developers not to rely on HFS+ resource forks,
> but rather to encapsulate the resource forks into "packages" so they
> will run on UFS.

I already told you that resource forks work on UFS. The push towards
data-fork-based resources has nothing to do with UFS.

> A good reason for abandoning HFS+ would be to make OSX more
> cross-platform friendly, to increase Apple's market share.

Why? Apple's UFS doesn't work with most other platforms as far as I
know.

-Eric

Eric Albert

unread,

Feb 26, 2003, 1:43:06 AM2/26/03

to

In article <b3h3lt$pjo$1...@pcls4.std.com>,
Tony Lawrence <a...@shell01.TheWorld.com> wrote:

> Lordy. You think a shell couldn't tell what sort of filesystem it was
> being asked to expand filenames upon?

Not easily, since it would dramatically decrease the performance of
filename expansion in the shell. You'd have to do a statfs every time
you changed directories, or check each path against a cached set of the
system's mount points. And since filename expansion almost certainly
happens via calls to glob(3) rather than a custom version of that same
code in each shell, you'd have to change that routine, which would then
also affect any other application that calls it. In general, it's much
better to simply assume either case-sensitivity or case-insensitivity.

Mark Conrad

unread,

Feb 26, 2003, 9:36:04 AM2/26/03

to

In article <ejalbert-977B7C...@news.stanford.edu>, Eric
Albert <ejal...@stanford.edu> wrote:

> I already told you that resource forks work on UFS. The push towards
> data-fork-based resources has nothing to do with UFS.

Okay, then I am really confused about why Apple is recommending to
their developers to eliminate resource forks.

I thought it was because resource forks might not work with UFS, but
apparently it is for different reasons altogether.

I will do more fiddling around with resource forks and UFS, perhaps I
will be able to understand the subject if I play with it some more.

Mark-

Mark Conrad

unread,

Feb 26, 2003, 9:36:12 AM2/26/03

to

In article <10462120...@ok-corral.gunslinger.net>, Jeremy
<jer...@exit109.com> wrote:

> Except that UFS stands for "Unified File System".

Not according to Apple's own "Disk Utility", which lists choices for
the desired file systems as:

Mac OS Extended
Mac OS Standard
UNIX File System

Mark Conrad

unread,

Feb 26, 2003, 9:36:21 AM2/26/03

to

In article <ejalbert-977B7C...@news.stanford.edu>, Eric

Albert <ejal...@stanford.edu> wrote:

> > According to statements made by some book authors
>
> Which book authors? I'm quite curious.

Specifically, Todd Stauffer, author of "Mastering Mac OS X", ISBN
0-7821-2581-6 page 676, which says in part:

"As cross-platform programs and data exchange between Macs and other
computers have become prevalent, emphasis has gradually shifted away
from resource forks, because they are useless on other platforms. To
simplify all this and make compatibility easier, Apple now encourages
developers to store resource information in data forks."

The author goes on with the details of exactly how Apple recommends to
their developers to eliminate the resource fork altogether.

Mark-

Mark Conrad

unread,

Feb 26, 2003, 9:36:28 AM2/26/03

to

In article <10462122...@ok-corral.gunslinger.net>, Jeremy
<jer...@exit109.com> wrote:

> >> It's slower...
> >
> > Not on a straight Unix box. Don't blame UFS for running slow, blame
> > Apple's implementation of UFS.
>
> You can't possibly be thinking that it's a good idea to us UFS on OS X
> because UFS is fast on some other versions of Unix? That doesn't even
> make sense.

Of course not, I was not implying that at all.

What I _am_ saying is that UFS has its own uses, other that the speed
angle, so I for one am going to take advantage of those uses, if the
occassion arises.

I have decided that I am going to use HFS+ as my main file system, but
if I have enough disk space I will place OSX in a UFS partition, just
in case I have need for that file system.

> Someone seems to have put the idea into your head that you'll

> need UFS to run regular Unix software...

Yep, I was thinking of applications which carried their own libraries,
such that there was a lot of case-sensitive path names that needed
changing before it would run with HFS+.

> ...but that is simply *not* true, not even remotely.

Hokay, if you say so... ;-)

I can't see the reason why it works that way, maybe when I learn a bit
more about Unix I might be able to figure it out.

Mark-

Mark Conrad

unread,

Feb 26, 2003, 9:36:36 AM2/26/03

to

In article <tph-026760.17310025022003@localhost>, Tom Harrington
<t...@pcisys.no.spam.dammit.net> wrote:

> > Not on a straight Unix box. Don't blame UFS for running slow, blame
> > Apple's implementation of UFS.
>
> Err... so what? If you're using a Mac, then it's the speed on the Mac
> that matters.

That's true enough, I was just addressing those posters who implied
that UFS was intrinsically slower than HFS+, i.e. someone mentioned
that because UFS was ancient, it was therefore not capable of running
as fast as "modern" HFS+. (on a straight Unix box)

Mark-

Mark Conrad

unread,

Feb 26, 2003, 9:36:44 AM2/26/03

to

In article <jimglidewell-D526...@netnews.attbi.com>, Jim
Glidewell <jimgli...@attbi.com> wrote:

> Grow up.

Why? - to me, growing up equates to losing one's childlike
imagination, which I fervently hope does not happen in my case.

Hmm, very little of what you posted deserves any reply.

> And use HFS+, as it is the superior solution...<clipped>...

I have decided to use HFS+ for my main file system, but if I have
enough spare disk space I will run another OS-10.2.4 with UFS, just in
case I have minor need for that file system.

> > I wanna create computer software that learns by itself, instead of
> > needing a programmer to tell it what to do every-step-of-the-way.
>
> You've had years to develop this using Lisp - what do you have to
> show for it? Nothing, it appears.

As I mentioned in an earlier post in this thread, I am a Lisp hobbyist,
not even close to being a competent developer of Lisp software.

As of right now, I have not ground out a line of Lisp code for years,
but I would like to slowly get back in the swing of playing with Lisp,
for recreation.

What I wanna do, and what I am capable of doing, are two entirely
different things.

> Too late for you, I'm afraid. Whatever smarts were once there appear to
> already be in a serious state of decay.

You got that right, but then it will most likely happen to all of us as
we age, won't it. When our hypothalamus shrinks, as it will in all of
us, our short-term memory goes bye-bye.

Imagine if all your air-traffic controllers were all over 80 years old,
and you get the picture quickly of what might happen to you on your
next airline flight.

> I can't imagine a worse world than one populated with senile robotic
> windbags, muttering about their stupid ingrate offspring.

I can, a world populated with knee-jerk teen-aged robotic
accidents-waiting-to-happen, the kind of robots who "know everything",
whose actions are guided by their silicon gonads instead of wisdom
gained from being properly aged, like fine wine.

The best compromise might be to download a human's brain when they are
liable to be the most productive, compassionate, rational, etc. - - -
say somewhere between the ages of 25-55 years old, depending on the
individual person.

Mark Conrad

unread,

Feb 26, 2003, 9:36:52 AM2/26/03

to

In article <20030225165841...@mb-fk.aol.com>, Tacit
<tac...@aol.com> wrote:

> Whether or not a filesystem can be mountede in OS 9 depends on two separate,
> distinct things:
>
> 1. If the disk has an OS 9 driver;
> 2. If the disk has a filesystem that OS 9 knows about and can mount.
>
> Don't confuse these two things. They are entirely unrelated.

Yeah, I found that out the hard way when I checked further, after I had
posted incorrectly that any OS9 partition would not mount on the
desktop when booting from a UFS partition - - - I have a nasty habit of
posting bum info before I really check things out.

Mark-

Eric Albert

unread,

Feb 26, 2003, 1:14:59 PM2/26/03

to

In article <260220030638562698%nos...@iam.invalid>,
Mark Conrad <nos...@iam.invalid> wrote:

> In article <ejalbert-977B7C...@news.stanford.edu>, Eric
> Albert <ejal...@stanford.edu> wrote:
>
> > I already told you that resource forks work on UFS. The push towards
> > data-fork-based resources has nothing to do with UFS.
>
> Okay, then I am really confused about why Apple is recommending to
> their developers to eliminate resource forks.

Because file utilities and protocols that don't know what resource forks
are don't copy them. For example, ls doesn't list them, cp doesn't copy
them, and all but Mac-specific FTP clients don't move them between
systems.

Eric Albert

unread,

Feb 26, 2003, 1:13:14 PM2/26/03

to

In article <260220030639204190%nos...@iam.invalid>,
Mark Conrad <nos...@iam.invalid> wrote:

> In article <ejalbert-977B7C...@news.stanford.edu>, Eric
> Albert <ejal...@stanford.edu> wrote:
>
> > > According to statements made by some book authors
> >
> > Which book authors? I'm quite curious.
>
> Specifically, Todd Stauffer, author of "Mastering Mac OS X", ISBN
> 0-7821-2581-6 page 676, which says in part:
>
> "As cross-platform programs and data exchange between Macs and other
> computers have become prevalent, emphasis has gradually shifted away
> from resource forks, because they are useless on other platforms. To
> simplify all this and make compatibility easier, Apple now encourages
> developers to store resource information in data forks."

OK...that doesn't include the word "waffling", which you'd quoted, and
it says nothing about UFS. The quote's completely right; it just
doesn't apply to this conversation.

Tony Lawrence

unread,

Feb 26, 2003, 6:16:28 AM2/26/03

to

Jeremy <jer...@exit109.com> wrote:
: Tony Lawrence <a...@shell01.TheWorld.com> wrote:

:> Yes, it IS just about expanding wildcards - where do you think the programs
:> get filenames from?

: They can also come from the user, or anywhere else.

Yes. So?

: Like I said, if all you're interested in is globbing, then sure, that would

: just mean modifying all the shells, a couple of library functions, and a
: few command line tools. Beyond that, you could just count on the filesystem
: to take care of the rest, but I don't think that would be quite enough.

If we haven't been talking about wild card expansion, just What HAVE we been
talking about?

:> As I said, only "find" takes raw wildcards for filenames that I can think

:> of.. yes, you are right about grep.

: Well, I believe pax does, and Perl does internal globbing now too (it used
: to fork a csh to do it).

Fine. So there are a very few things that can take raw wildcards and those
few things need to be modified to work correctly.

Tony Lawrence

unread,

Feb 26, 2003, 6:24:04 AM2/26/03

to

Eric Albert <ejal...@stanford.edu> wrote:
: In article <b3h3lt$pjo$1...@pcls4.std.com>,
: Tony Lawrence <a...@shell01.TheWorld.com> wrote:

Actually, it's better to not have case insensitive/case preserving
filesystems. If it's not case preserving you don't have this foolishness.

If you WANT case insensitive/case preserving (and I personally think
it is a dumb combination) then yes, the shell needs to stat or cache.

The issue isn't "easy" or performance. If you have HFS+, wildcards
do not work properly. If the shell doesn't fix that, then the user
has to, and the whole original justification of case insensitive/case
preserving was supposedly to make it easy for the poor ignorant user.

You can't have it both ways: you can't say the user needs ci/cp to
make their life easier and then make it harder by tools that don't
work correctly.

--
to...@aplawrence.com Unix/Linux resources: http://aplawrence.com
Inexpensive phone/email support
Download Free Linux Skills Test: http://pcunix.com/skilltests.html

: --

Jerry Kindall

unread,

Feb 26, 2003, 3:05:18 PM2/26/03

to

In article <b3i84k$mvr$2...@pcls4.std.com>, Tony Lawrence
<a...@shell01.TheWorld.com> wrote:

> The issue isn't "easy" or performance. If you have HFS+, wildcards
> do not work properly. If the shell doesn't fix that, then the user
> has to, and the whole original justification of case insensitive/case
> preserving was supposedly to make it easy for the poor ignorant user.

Anyone using a command line to begin with is by no means ignorant, and
can easily deal with this issue.

--
Jerry Kindall, Seattle, WA
http://www.jerrykindall.com/

Jeremy

unread,

Feb 26, 2003, 3:16:47 PM2/26/03

to

Mark Conrad <nos...@iam.invalid> wrote:

>> Except that UFS stands for "Unified File System".
>
> Not according to Apple's own "Disk Utility", which lists choices for
> the desired file systems as:
>
> Mac OS Extended
> Mac OS Standard
> UNIX File System

That doesn't say that UFS stands for "Unix File System", any more than it
says HFS+ stands for "Mac OS Extended".

--
Jeremy | jer...@exit109.com

Jeremy

unread,

Feb 26, 2003, 3:19:17 PM2/26/03

to

Mark Conrad <nos...@iam.invalid> wrote:

> What I _am_ saying is that UFS has its own uses, other that the speed
> angle, so I for one am going to take advantage of those uses, if the
> occassion arises.

But you still haven't pointed out what those uses actually *are*.

>> Someone seems to have put the idea into your head that you'll
>> need UFS to run regular Unix software...
>
> Yep, I was thinking of applications which carried their own libraries,
> such that there was a lot of case-sensitive path names that needed
> changing before it would run with HFS+.

What applications are those? You still haven't managed to come up with
any that need this kind of treatment.

--
Jeremy | jer...@exit109.com

Mark Conrad

unread,

Feb 27, 2003, 7:56:24 AM2/27/03

to

In article <10462906...@ok-corral.gunslinger.net>, Jeremy
<jer...@exit109.com> wrote:

> >> Except that UFS stands for "Unified File System".
> >
> > Not according to Apple's own "Disk Utility", which lists choices for
> > the desired file systems as:
> >
> > Mac OS Extended
> > Mac OS Standard
> > UNIX File System
>
> That doesn't say that UFS stands for "Unix File System", any more than it
> says HFS+ stands for "Mac OS Extended".

Thanks very much for pursueing this subject, I know it is a bunch of
work to educate newbies - - - anyhow, thanks.

I did some digging into my books, most of those books misled me as to
the exact meaning of UFS, with one notable exception.

Here is what I found, note the last entry:
*********************************************
Mac OSX Unleashed pg 62 -
"and choose a type of partition (Mac OS Extended [HFS+], or UNIX File
System [UFS], from the pop-op menu."

...index, pg 1461 under "U" -
"UFS (UNIX File System), 62"

Mac OSX Black Book pg 167 -
"The Unix File System (UFS) can be used as the preferred volume format
for Mac OS X. Unix users may prefer the UFS standard over HFS+"

Mac OSX Bible pg 20 -
"Naturally, it works with the established Mac OS Extended format (also
known as HFS+)"

"in addition, Mac OS X extends support to Universal File System (UFS)
format, which is similar to the standard format of most UNIX volumes"
**********************************************

It certainly pays to have many books, the Mac OSX Bible got it right.

Mark-

Howard S Shubs

unread,

Feb 27, 2003, 7:43:35 AM2/27/03

to

In article <250220031312443197%nos...@iam.invalid>,
Mark Conrad <nos...@iam.invalid> wrote:

> In a way, the file system and Unix _are_ inseperable, such that when
> I pick a file system I am stuck with it, warts and all. If I suddenly
> decide I want the features of a different file system, I hafta set
> aside another partition for Unix in order to use the 'other' file
> system. This can take a prohibative amount of disk space.

Given that of the UNIX systems I manage at work, only one uses UFS, I'd
call them VERY separable. The rest use various things developed in the
last 20 years or less.

--
Today, on Paper-view: The World Origami Championship

Tony Lawrence

unread,

Feb 27, 2003, 8:06:44 AM2/27/03

to

Jerry Kindall <jerryk...@nospam.invalid> wrote:
: In article <b3i84k$mvr$2...@pcls4.std.com>, Tony Lawrence
: <a...@shell01.TheWorld.com> wrote:

:> The issue isn't "easy" or performance. If you have HFS+, wildcards
:> do not work properly. If the shell doesn't fix that, then the user
:> has to, and the whole original justification of case insensitive/case
:> preserving was supposedly to make it easy for the poor ignorant user.

: Anyone using a command line to begin with is by no means ignorant, and
: can easily deal with this issue.

I don't entirely disagree, but I make that mistake at least a couple
of times a month, and it's annoying.

Realistically, nobody is going to rewrite the shells etc.

The real problem is this silly case insensitivity, which some of
us (me and I'm sure others) find annoying and dumb.

So how about a mount switch that would let those of us who don't
want case insensitivity turn it off? I would suspect that the fs
code that makes it case insensitive would be fairly simple to
jump around; a switch like that would let the people who like
this have it, and those who don't could shut it off.

I don't think any app would be affected by that.

Mark Conrad

unread,

Feb 27, 2003, 8:39:06 AM2/27/03

to

In article <ejalbert-BFF1B3...@news.stanford.edu>, Eric
Albert <ejal...@stanford.edu> wrote:

> OK...that doesn't include the word "waffling", which you'd quoted, and
> it says nothing about UFS. The quote's completely right; it just
> doesn't apply to this conversation.

Granted, my quotes were out of place, and it has no relevance to UFS.

I thought it did have relevance to UFS, however Eric and Jeremy helped
me get my head on straight about that issue, see our recent posts.

As a Unix newbie, I guess I am prone to stir up irrelevant clouds of
dust about many Unix issues, sorry.

Mark-

Mark Conrad

unread,

Feb 27, 2003, 8:39:17 AM2/27/03

to

In article <ejalbert-00E215...@news.stanford.edu>, Eric
Albert <ejal...@stanford.edu> wrote:

> > Okay, then I am really confused about why Apple is recommending to
> > their developers to eliminate resource forks.
>
> Because file utilities and protocols that don't know what resource forks
> are don't copy them. For example, ls doesn't list them, cp doesn't copy
> them, and all but Mac-specific FTP clients don't move them between
> systems.

Okay, you have clarified the reason admirably, thanks.

Like you said initially, the reason has nothing to do with the
Universal File System (UFS) - because the problems with "ls" and "cp"
still occur when HFS+ is being used.

It is tough getting all these subtle things under my belt. Think I
will file your posts just in case I forget these things in the future.

Thanks again,

Mark-

Mark Conrad

unread,

Feb 27, 2003, 8:39:25 AM2/27/03

to

In article <10462907...@ok-corral.gunslinger.net>, Jeremy
<jer...@exit109.com> wrote:

Regarding Mark's reason for keeping a UFS (Universal File System)
volume on his hard drive -

> But you still haven't pointed out what those uses actually *are*.

- - - and - - -

> What applications are those? You still haven't managed to come up with
> any that need this kind of treatment.

Upon further reflection, I think you are correct - why should I tie up
that expensive real estate on my disk when I have no definite idea as
to why I am doing it.

You have just saved me 7GBs of disk space :)

Mark-

Jim Glidewell

unread,

Feb 27, 2003, 12:30:26 PM2/27/03

to

In article <b3i7mc$mvr$1...@pcls4.std.com>, Tony Lawrence <a...@shell01.TheWorld.com> wrote:

> : Like I said, if all you're interested in is globbing, then sure, that would
> : just mean modifying all the shells, a couple of library functions, and a
> : few command line tools. Beyond that, you could just count on the filesystem
> : to take care of the rest, but I don't think that would be quite enough.
>
> If we haven't been talking about wild card expansion, just What HAVE we been
> talking about?
>
> :> As I said, only "find" takes raw wildcards for filenames that I can think
> :> of.. yes, you are right about grep.
>
> : Well, I believe pax does, and Perl does internal globbing now too (it used
> : to fork a csh to do it).
>
> Fine. So there are a very few things that can take raw wildcards and those
> few things need to be modified to work correctly.

IMHO, your idea of how to "correctly" handle file name expansion under HFS+
is not a desirable one.

In the interest of making the command line more "friendly to newbies" and
the overall handling of mixed case more consistent, your ideal of having
file expansion match regardless of case has the potential of breaking a
large number of scripts.

When I put a "rm xyz*" in a script, I expect it to remove *only* files
starting with the string "xyz" and not those starting with "Xyz" or
"XYZ" or ...

I think that case-insensitive file globbing is a terrible idea for the
default shell behavior, and dangerous enough that I don't even think
it's desirable as an _option_.

I also tend to think that trying to make the shells "newbie friendly"
is really rather pointless. For folks to make decent usage of the
Unix command line facility, they need to *learn* stuff. The fact that
"the shells respect case, the finder doesn't" is not a huge additional
burden on anyone who has enough interest to pursue becoming at all
proficient with the command line.

Making the shells on OSX behave differently than any other Unix
platform in the world should be done only for *very* good reasons.
I haven't seen any here.

--
Jim Glidewell
My opinions only

unread,

Feb 28, 2003, 1:39:44 PM2/28/03

to

In article <270220031206335757%dogb...@chaseabone.com.invalid>, sbt
<dogb...@chaseabone.com.invalid> wrote:

> > "in addition, Mac OS X extends support to Universal File System (UFS)
> > format, which is similar to the standard format of most UNIX volumes"
>

> As one of the authors (and the one who wrote that part), thank you for
> the kind words. Which of the authors I am is left as an exercise :)

Given that I like to use all the available tools in OSX, even the
obscure tools, do you happen to know offhand where I can find out more
about the Universal File System, namely why it was created?

I suspect that the developers of UFS had more in mind than mere
case-sensitivity of filenames.

I have a hunch that if I tried Google, I would get too many hits.

Mark-

Tom Stiller

unread,

Feb 28, 2003, 2:38:05 PM2/28/03

to

In article <280220031043187221%nos...@iam.invalid>,
Mark Conrad <nos...@iam.invalid> wrote:

There's one sure way to find out.

--
Tom Stiller

PGP fingerprint = 5108 DDB2 9761 EDE5 E7E3 7BDA 71ED 6496 99C0 C7CF

unread,

Mar 1, 2003, 10:42:45 PM3/1/03

to

In article <10465535...@ok-corral.gunslinger.net>, Jeremy
<jer...@exit109.com> wrote:

> The one I cracked open to double-check the expansion of "UFS" was
> "Advanced Programmming in the Unix Environment", because I remembered
> that it was in there.

Thanks, your quick recall of that title saved me a whole bunch of time
if I had tried to get the info myself.

For one thing, I was not even aware that the search tricks of:

www.amazon.com/exec/obidos/search-handle-url/field-author etc., etc.

...were available, nor am I even now aware of how to use such search
techniques to find the books written by a particular author.

At least now I know that such search techniques are available in
amazon.com. All I have to do is figure out where they are described,
most likely somewhere within amazon's web site.

I plan to buy the book you refered to. With any luck, there may be
something in there comparing the various file systems to each other,
with the relative advantages of one filesystem compared to other
filesystems.

Mark-

Jeremy

unread,

Mar 2, 2003, 1:14:36 AM3/2/03

to

Mark Conrad <nos...@iam.invalid> wrote:

> At least now I know that such search techniques are available in
> amazon.com. All I have to do is figure out where they are described,
> most likely somewhere within amazon's web site.

Yes, it's a very involved, technical procedure, which a few of us managed
to learn after years of toiling over arcane Unix manuals. I'm not sure I
can adequately walk you through the process, but since you seem eager to
learn, I'll try.

Step 1: Go to http://www.amazon.com in your favorite browser.

Step 2: On the left side of the page, there is a little box; at the top,
it says "Search". Select "Books" from the pop-down menu.

Step 3: Click in the text field to give it focus, and enter "Richard W.
Stevens".

Step 4: Press the Return key on your keyboard, or click the "Go" button.

I hope you can follow that; I tried to write it a bit more clearly than
a Unix man page might be. If you need anything clarified, please don't
hesitate to follow up.

> I plan to buy the book you refered to. With any luck, there may be
> something in there comparing the various file systems to each other,
> with the relative advantages of one filesystem compared to other
> filesystems.

There's not. It's a Unix programming book, and since it was written in
1993, the detailed filesystem description isn't actually even about UFS.
Also since it was written in 1993, it's not going to have much specific
information about OS X, and it won't mention HFS+ so much either. There
is quite a lot of information in it about Unix, and it could, in theory,
be an enormous wealth of the kind of basic, fundamental Unix knowledge
that you've already said you're not interested in.

--
Jeremy | jer...@exit109.com

Jeremy

unread,

Mar 2, 2003, 1:18:15 AM3/2/03

to

Jeremy <jer...@exit109.com> wrote:

> Step 3: Click in the text field to give it focus, and enter "Richard W.
> Stevens".

Geez; maybe I am writing man pages. I meant "W. Richard Stevens," of course.

--
Jeremy | jer...@exit109.com

Mark Conrad

unread,

Mar 2, 2003, 4:45:23 PM3/2/03

to

In article <10465856...@ok-corral.gunslinger.net>, Jeremy
<jer...@exit109.com> wrote:

> > At least now I know that such search techniques are available in
> > amazon.com. All I have to do is figure out where they are described,
> > most likely somewhere within amazon's web site.
>
> Yes, it's a very involved, technical procedure, which a few of us managed
> to learn after years of toiling over arcane Unix manuals. I'm not sure I
> can adequately walk you through the process, but since you seem eager to
> learn, I'll try.

Okay, so you are pulling my leg <chuckle>

I thought there was something very involved about 'learning' a search
string or something, but such was not the case.

> > I plan to buy the book you refered to. With any luck, there may be
> > something in there comparing the various file systems to each other,
> > with the relative advantages of one filesystem compared to other
> > filesystems.
>
> There's not.

Darn, bummer. Since that subject is the main topic of this thread, I
will have to look elsewhere for that specific info.

I already know that HFS+ for example is prone to become very
fragmented, whereas UFS does not (so they tell me)

I also know that Apple presently has a lot of stuff in their OSX "tied"
to the HFS+ system, such that if I use UFS instead, I will be hurting
in several respects.

I can live with all that. I don't mind having to defrag HFS+
occassionally as the price for the benefits of using Apple's favored
file system, namely HFS+.

What worries me a little is the following -

A file systems main job is to keep track of, er, "files"

Now HFS+ treats a file as a file, but UFS "extends" the idea of a file
to apply to other things also, like a disk-drive, or a keyboard, or a
display-screen, or any number of other "devices".

With HFS+, a file is a file, and a device is _not_ a file, as HFS+
was originally intended to be with older Apple OSs like OS9.

Now Apple has bastardized HFS+ to be something it was not intended to
be originally when HFS+ was first designed by Apple developers. Apple
has changed HFS+ within OSX so it now recognizes a device as being a
"file".

Seems to me this could be the source of bugs, when switching between
different file systems.

This is probably the reason Apple "recommends" using HFS+, to avoid
such bugs.

In such a case we can't really use other file systems like UFS, as
Apple claims we can, without the penalty of encountering such bugs.

About the book -
> ...and it could, in theory, be an enormous wealth of the kind of basic,

> fundamental Unix knowledge that you've already said
> you're not interested in.

Right now I find information about Unix file-shuffling to be very
boring, tedious, time-consuming, which is why I avoid general Unix
textbooks. Obviously, I will have to eventually learn the basics, but
right now my interests are with the more exotic stuff associated with
the Unix command line.

When I am hampered and handicaped in learning the "interesting"
advanced stuff, I will begrudgingly learn just enough of the basics to
allow me to progress further in learning the advanced stuff.

My approach to learning Unix irritates the hell out of certain types of
Unix people, who throw insults and discouragement my way.

I don't give a rats ass about their opinion of me, that is their
problem, not mine.

Every day I learn more about Unix, and eventually I will have enough
Unix under my belt to be fairly adept at using it, with or without the
help of the horses asses like Mr. Glidewell and Mr. Stiller.

Mark-

Jeremy

unread,

Mar 2, 2003, 5:23:14 PM3/2/03

to

Mark Conrad <nos...@iam.invalid> wrote:

> What worries me a little is the following -
>
> A file systems main job is to keep track of, er, "files"
>
> Now HFS+ treats a file as a file, but UFS "extends" the idea of a file
> to apply to other things also, like a disk-drive, or a keyboard, or a
> display-screen, or any number of other "devices".

It's Unix that treats devices as files. The filesystem just has to
support different types of files; beyond that, it's an OS thing, not
a filesystem thing. Unix systems which use filesystems other than UFS
still use special device files.

(Using files for almost everything is a simplification feature. You're
the first person I think I've ever seen who finds it a complication.)

> Right now I find information about Unix file-shuffling to be very
> boring, tedious, time-consuming, which is why I avoid general Unix
> textbooks. Obviously, I will have to eventually learn the basics, but
> right now my interests are with the more exotic stuff associated with
> the Unix command line.

But if you had a firm grasp of the basics, the advanced stuff would come
easily.

--
Jeremy | jer...@exit109.com

Christopher W Aiken

unread,

Mar 2, 2003, 5:25:59 PM3/2/03

to

In article <10465856...@ok-corral.gunslinger.net>,
Jeremy <jer...@exit109.com> wrote:

> Mark Conrad <nos...@iam.invalid> wrote:
>
> > At least now I know that such search techniques are available in
> > amazon.com. All I have to do is figure out where they are described,
> > most likely somewhere within amazon's web site.
>
> Yes, it's a very involved, technical procedure, which a few of us managed
> to learn after years of toiling over arcane Unix manuals. I'm not sure I
> can adequately walk you through the process, but since you seem eager to
> learn, I'll try.
>
> Step 1: Go to http://www.amazon.com in your favorite browser.
>
> Step 2: On the left side of the page, there is a little box; at the top,
> it says "Search". Select "Books" from the pop-down menu.
>
> Step 3: Click in the text field to give it focus, and enter "Richard W.
> Stevens".
>
> Step 4: Press the Return key on your keyboard, or click the "Go" button.
>
> I hope you can follow that; I tried to write it a bit more clearly than
> a Unix man page might be. If you need anything clarified, please don't
> hesitate to follow up.
>

Heh Heh Heh... Kool...

--
-=[cwa]=-

A bus station is where a bus stops.
A train station is where a train stops.
On my desk, I have a work station........

to...@aplawrence.com

unread,

Mar 2, 2003, 6:15:55 PM3/2/03

to

Mark Conrad <nos...@iam.invalid> wrote:

: A file systems main job is to keep track of, er, "files"

: Now HFS+ treats a file as a file, but UFS "extends" the idea of a file
: to apply to other things also, like a disk-drive, or a keyboard, or a
: display-screen, or any number of other "devices".

: With HFS+, a file is a file, and a device is _not_ a file, as HFS+
: was originally intended to be with older Apple OSs like OS9.

Completely wrong idea, Mark. It isn't UFS, it's UNIX that treats
everything as a file. See http://aplawrence.com/Unixart/devices.html
Absolutely NOTHING to do with the filesystem.

And in any case, it's nothing but an abstraction anyway.. a convenience
that allows us to use "open", "read" etc. on devices. But it has
nothing to do with the file system itself.

Michael Newbery

unread,

Mar 2, 2003, 7:50:57 PM3/2/03

to

In article <020320031347192887%nos...@iam.invalid>,
Mark Conrad <nos...@iam.invalid> wrote:

> I already know that HFS+ for example is prone to become very
> fragmented, whereas UFS does not (so they tell me)
>
> I also know that Apple presently has a lot of stuff in their OSX "tied"
> to the HFS+ system, such that if I use UFS instead, I will be hurting
> in several respects.
>
> I can live with all that. I don't mind having to defrag HFS+
> occassionally as the price for the benefits of using Apple's favored
> file system, namely HFS+.
>

[snip]

> Now Apple has bastardized HFS+ to be something it was not intended to
> be originally when HFS+ was first designed by Apple developers. Apple
> has changed HFS+ within OSX so it now recognizes a device as being a
> "file".
>
> Seems to me this could be the source of bugs, when switching between
> different file systems.
>
> This is probably the reason Apple "recommends" using HFS+, to avoid
> such bugs.
>
> In such a case we can't really use other file systems like UFS, as
> Apple claims we can, without the penalty of encountering such bugs.

'File System' is a rather overloaded term. For a start, there is
implementation to be aware of. Some features have to do with how
efficient the file system is---how the underling structure is designed.
Other with fetures exposed to the user. For example:

File name:
255 Unicode characters in HFS+. cf 20 ASCII in HFS, 11 ASCII in FAT16
(?). UFS is 255 ASCII I think.
Case preserving in HFS+ (like NTFS, FAT and others). cf case
sensitive in UFS, ext2/3, ReiserFS and most Unix/Linux FS.

Metadata:
E.g. User/group/system permissions. Creation/modify/access/backup
date. Owner (user/group), file type/creator. inode. File ID, etc etc.

This was a big thing in HFS->HFS+. While HFS had file type/creator, it
lacked all the Unix 'ownership' information. When Apple designed HFS+
they made it able to supoprt all the Unix permissions---long before it
was settled that Unix was what the new Mac OS would be based on.

Multiple forks:
I.e. resource and data. NTFS and Novell (NWFS, NSS) also offer this
(NTFS allows an arbitrary number of forks). NOT to be confused with
Metadata. UFS simulates this with some artful renaming. Mac OS X
packages are aiming to obsolete this anyway.

File size:
TB in HFS+. GB in HFS. Depends on whether fields in the file
structure are 64 bits or 32 bits. Very difficult to fix without
radically changing the file system.

Journalling:
HFS+ supports it, as do ext3 and ReiserFS on Linux, and UFS on
FreeBSD (but not on Mac OS X).

File structure:
HFS+ is a B-Tree based system---as was HFS. This is considered a Good
Thing and is one of the claims to fame of ReiserFS. The new Novell NSS
is also B-Tree, the old NWFS not.

Implmentation:
Sun optimises UFS to make it run very fast, where Linux abandoned it
in favour of better (ext2/3, Reiser, xfs) fundamental design. FreeBSD
also gets great performance out of ufs, but is replacing it with ufs2.
MacOS X suffers from very much less fragmentation than Mac OS, even on
HFS+.

In summary---use HFS+ on Mac OS X. The only thing UFS, in the current
Mac OS X implementation, offers that HFS+ does not is CaSe SeNsItivitY.
HFS+ is, in absolute terms, quite a good file system. Its implmentation
could be improved of course, but that is probably a truism for ANY OS
and file system.
--
Michael Newbery
return address is spamtrapped.
surname at "actrix", 2ld "co", tld "nz"

Mark Conrad

unread,

Mar 2, 2003, 10:34:31 PM3/2/03

to

In article <nopottedmeat-DCF9...@copper.ipg.tsnz.net>,
Michael Newbery <nopott...@nowhere.invalid> wrote:

> [snip]

Very good constructive post of yours, gets to the meat of the issue.

> > I already know that HFS+ for example is prone to become very
> > fragmented, whereas UFS does not (so they tell me)
>

> MacOS X suffers from very much less fragmentation than Mac OS, even on
> HFS+.

Forgive me, but it does not appear to be that way, when I look at
SpeedDisk's visual map of severe file fragmentation on OSX, just before
I defrag the OSX HFS+ partition.

> Multiple forks:
> I.e. resource and data. NTFS and Novell (NWFS, NSS) also offer this
> (NTFS allows an arbitrary number of forks). NOT to be confused with
> Metadata. UFS simulates this with some artful renaming. Mac OS X
> packages are aiming to obsolete this anyway.

That's what I heard also, namely that 'packages' are being recommended
by Apple to the developer community as a way of getting around the
trouble that seperate forks cause. I think that with packages, both
forks are turned into regular files, the resource file having a
slightly different name than the data file.

> Journalling:
> HFS+ supports it, as do ext3 and ReiserFS on Linux, and UFS on
> FreeBSD (but not on Mac OS X).

I read somewhere that journalling is now supported in the latest
releases of OSX, is that correct.

> Metadata:
> E.g. User/group/system permissions. Creation/modify/access/backup
> date. Owner (user/group), file type/creator. inode. File ID, etc etc.
>
> This was a big thing in HFS->HFS+. While HFS had file type/creator, it
> lacked all the Unix 'ownership' information. When Apple designed HFS+
> they made it able to supoprt all the Unix permissions---long before it
> was settled that Unix was what the new Mac OS would be based on.

Okay then, I was obviously wrong about HFS+ not being originally
designed to support user/group/system permissions.

Another thing I am unclear about. Are you saying that HFS+ could
support case sensitivity, i.e. be able to tell that the file
My-File.txt was a different file than the file my-file.txt ???

If that is correct, then Apple could supply an OSX switch to allow a
user to switch between case-sensitive or case-insensitive, making
everyone happy.

Mark-

Mark Conrad

unread,

Mar 2, 2003, 11:17:52 PM3/2/03

to

In article <b3u3bb$739$2...@pcls4.std.com>, <to...@aplawrence.com> wrote:

> : A file systems main job is to keep track of, er, "files"
>
> : Now HFS+ treats a file as a file, but UFS "extends" the idea of a file
> : to apply to other things also, like a disk-drive, or a keyboard, or a
> : display-screen, or any number of other "devices".
>
> : With HFS+, a file is a file, and a device is _not_ a file, as HFS+
> : was originally intended to be with older Apple OSs like OS9.
>
> Completely wrong idea, Mark. It isn't UFS, it's UNIX that treats
> everything as a file. See http://aplawrence.com/Unixart/devices.html
> Absolutely NOTHING to do with the filesystem.
>
> And in any case, it's nothing but an abstraction anyway.. a convenience
> that allows us to use "open", "read" etc. on devices. But it has
> nothing to do with the file system itself.

Okay, I did not realize it was an abstraction, I thought the underlying
file system had to support it also.

What you say makes sense. For example, dev/disk5 can not be split up
into two partial files to be stored in different places on the disk,
like a 'regular' file can, because dev/disk5 is not really a file,
despite the fact that OSX/Unix tries to treat it like one.

Very confusing, one would think that the creators of Unix could have
came up with a more realistic abstraction.

But then, who am I to complain, when I gladly tolerate the idea of
throwing an external disk-drive icon into the trash can, just to
unmount it from the desktop.

I wonder how many new Mac users think they are destroying their
external disk drive by throwing it into the trash ;-)

Mark-

Ernie Klein

unread,

Mar 2, 2003, 11:12:40 PM3/2/03

to

In article <020320031938054183%nos...@iam.invalid>,
Mark Conrad <nos...@iam.invalid> wrote:

>
> I read somewhere that journalling is now supported in the latest
> releases of OSX, is that correct.

From everything I have read, journalling is supported on OS X _Server_,
which is not the same as OS X. That doesn't mean that journaling
doesn't work on OS X, I have it turned on and it seems to work just
fine. Apple just doesn't _support_ using journaling on OS X yet.

--
-Ernie-

"There are only two kinds of computer users -- those who have
suffered a catastrophic hard drive failure, and those who will."

Have you done your backup today?

Michael Newbery

unread,

Mar 3, 2003, 12:04:46 AM3/3/03

to

In article <020320031938054183%nos...@iam.invalid>,

Mark Conrad <nos...@iam.invalid> wrote:
> > MacOS X suffers from very much less fragmentation than Mac OS, even on
> > HFS+.
>
> Forgive me, but it does not appear to be that way, when I look at
> SpeedDisk's visual map of severe file fragmentation on OSX, just before
> I defrag the OSX HFS+ partition.

For other reasons, Mac OS X tends to be fragmented after installation.
This has been discussed by the DiskWarrior folk I believe. It's an
artifact of the current Mac OS X. Once you have it defragged, it tends
to stay that way though, at least under Mac OS X. In practice however,
disk fragmentation doesn't actually matter that much. Very few people
ever really NEED to defrag their disks.
BTW, one point of confusion is that the Unix folk have tended to use
'fragmented' to mean something rather different to what the Windows/Mac
folk do. I can't at the moment recall the precise difference I'm afraid.

> That's what I heard also, namely that 'packages' are being recommended
> by Apple to the developer community as a way of getting around the
> trouble that seperate forks cause. I think that with packages, both
> forks are turned into regular files, the resource file having a
> slightly different name than the data file.

No, that's how UFS handles forks under Mac OS X. A package turns all the
individual RESOURCES into their own files (more or less). BTW, I checked
the HFS+ spec and it actually allows for an arbitrary number of named
forks, like NTFS. At the moment only the classic Mac two are implemented
though.

>
>
> > Journalling:
> > HFS+ supports it, as do ext3 and ReiserFS on Linux, and UFS on
> > FreeBSD (but not on Mac OS X).
>
> I read somewhere that journalling is now supported in the latest
> releases of OSX, is that correct.

Supported under Mac OS X server. Not 'supported'---but runs just
fine---under Mac OS X workstation. I'd guess it will quietly be made
available on 10.3 or somesuch.

> Another thing I am unclear about. Are you saying that HFS+ could
> support case sensitivity, i.e. be able to tell that the file
> My-File.txt was a different file than the file my-file.txt ???

I'd say it could, but I doubt it would. I can think of two ways to make
it happen. One would be a flag at the disk level saying 'this is a Case
SENSITIVE HFS+ disk'. The other would be to allocate a script/language
tag to the file name that said 'this UNICODE name is case sensitive
English'. The latter of course woulkd run into problems if "MyFile" was
tagged case insentive and "MYFILE" was tagged case sensitive.

>
> If that is correct, then Apple could supply an OSX switch to allow a
> user to switch between case-sensitive or case-insensitive, making
> everyone happy.

I think the resultant confision (ESPECIALLY from my 2nd suggestion:)
would be a cure worse than the disease. Bear in mind that it would need
to be done at the time the file system was set up, not on the fly.

Mark Conrad

unread,

Mar 3, 2003, 5:08:21 AM3/3/03

to

In article <nopottedmeat-8AD4...@copper.ipg.tsnz.net>,
Michael Newbery <nopott...@nowhere.invalid> wrote:

> > If that is correct, then Apple could supply an OSX switch to allow a
> > user to switch between case-sensitive or case-insensitive, making
> > everyone happy.
>

> I think the resultant confusion...<snipped>...

Yeah, you are right, come to think of it. If it was user selectable,
some users would prefer it one way and other users would prefer it
another way. That would cause real confusion, when transfering files
between computers.

Dang, looks like we are permanently stuck with the present situation
where some file systems are case sensitive, while other file systems
are not.

Mark-

Lars Duening

unread,

Mar 3, 2003, 8:49:16 PM3/3/03

to

Michael Newbery <nopott...@nowhere.invalid> wrote:

> BTW, one point of confusion is that the Unix folk have tended to use
> 'fragmented' to mean something rather different to what the Windows/Mac
> folk do. I can't at the moment recall the precise difference I'm afraid.

Better Unix filesystems allow to split a single block into several
equally sized 'fragments', and use these to store small files resp. the
ends of files.

For example on a filesystem with 4KB blocks and 1KB fragments, an 11KB
file would be stored in one 4KB block and one three-fragment portion of
a block (3KB). The remaining 1KB from that fragmented block is available
for some other file.

(Source: McKusick et al: The Design and Implementation of the 4.4 BSD
Operating System)

Tom Stiller

unread,

Mar 3, 2003, 10:07:42 PM3/3/03

to

In article <1fr9aev.q8kqkbqpqta8N%la...@bearnip.com>,
la...@bearnip.com (Lars Duening) wrote:

HFS+ can be configured to use 1K blocks by formatting the drive or
partition with Alsoft's PlusMaximizer. I have my 60 BG internal drive
formatted that way because my use of OS X generates many small files.

Lars Duening

unread,

Mar 4, 2003, 1:10:21 PM3/4/03

to

Tom Stiller <tomst...@comcast.net> wrote:

*nod* The reason that the Unix filesystems did this was to improve disk
throughput: the larger the blocks, the less time the disk has to spend
seeking between sectors.

It's interesting to note that the BeFS used a similar approach: while
its typical blocksize defaulted to 1KByte, it allocated disk space for
files in 64KByte chunks (as long as there was enough space left) - again
so that large parts of a file could be read in one transfer.