Slashdot Mirror


Unix File System Issues on Mac OS X?

rlthomps-1 asks: "I've been thinking about reformatting my Mac's hard drive in UFS, since I've seen the option on the install screen. I was looking for advantages of the Unix file system since it sounds like it would have better performance over HFS+. After viewing this Apple kbase article I wasn't so sure. A test system at work won't install software correctly because the drive name is stuck as '/' among other problems. Why would Apple include the UFS option if it offers such reduced functionality, and is anyone out there using it for non-server applications? What for? Are there advantages to UFS on the desktop Mac OS?"

47 of 93 comments (clear)

  1. UFS is there for historical reasons by Matthias+Wiesmann · · Score: 4, Insightful
    As far as I understand, UFS support in OS X is mostly legacy: previous versions (Mac OS X server 1.0 for instance) relied more heavily on it. In Mac OS X, HFS+ has been optimised more heavily than UFS.

    Also understand that many carbon applications have trouble coping with non-HFS+ file-systems. Here in the lab, I mount my solaris home directory thru NFS, and some carbon apps cannot start from my home directory because of this. Some carbon applications even have trouble with files in this file-system (on bad days Acrobat Reader tells me the file does not exist).

    As applications and system frameworks become more file-system agnostic. I suspect Apple will probably put less emphasis on HFS+ and put more effort in other file-systems.

  2. HFS+ versus UFS by Tsk · · Score: 5, Informative
    First let see the state of UFS in Darwin:
    When Darwin was built, Apple used FreeBSD 3.2 has its core BSD os, since then many changes where applied in the UFS code in FreeBSD (softupdates are the ones comes to mind). Since then Apple's version of UFS has not change too much.
    HFS+ is Apple's MacOS native enhanced file system. So if you need to run Classic, if you need to run carbonised application that do have a resource fork then you need an HFS+ partition (see Mozilla's readme).
    If you're more a unix guy like and want to compile OSS, host some CVS reposiroty then you 'll need UFS.
    UFS is case sensitive. HFS+ is not (it might seems to be but is not). I'de say for all macos Apps use HFS+ an create a second UFS partition where you'd put all your unix apps and other unix related stuff (CVS etc ...).
    Other references can be found :
    1. Open Darwin's Thread UFS vs HFS+
    2. Brigging UFS up to date
    3. Meta Data in Mac Filesystems
    --
    none Yet.
    1. Re:HFS+ versus UFS by usr122122121 · · Score: 5, Informative
      UFS is case sensitive. HFS+ is not (it might seems to be but is not)
      Minor addition to your post: UFS is case sensitive [and as a result has to be case-retaining]. HFS+ is case-insensitive, but is still case-retaining.
      --

      -braxton
    2. Re:HFS+ versus UFS by stux · · Score: 3, Informative

      The simple answer is...

      Use HFS+.

      Unless you have a concrete reason to use UFS... and no, wanting to have to get the case right, or wanting "better performance" is not a reason.

      HFS+ is the native file system of Mac OS X... UFS is just a compatibility layer.

      Just like Classic is a compatibility layer...

      You don't want to use Classic do you?

      Well, then you don't want to use UFS.

      UFS does not get tested as heavily as HFS+ (hell why do you think AirPort doesn't work... because it makes case insensitive assumptions)

      Commercial software is NOT tested on UFS.

      UFS is ONLY there to allow the porting of large unix software which makes case sensitive assumption... such as having two files with the same name in the same directory, but different cases.

      Running such software is the only valid reason to install UFS, and normally you'd just fix the problem anywho, doing this (the same files in the one directory) is bad practise anywho.

      So, the moral of the story is, don't use UFS on Mac OS X. (unless you have a DAMN good reason)

      (developing cross-platform UNIX software is actually a fairly good reason to have one UFS partition about)

      --

      ---
      Live Long & Prosper \\//_
      CYA STUX =`B^) 'da Captain,
      Jedi & Last *-fytr
  3. Yes advantages by Leimy · · Score: 3, Informative

    If you are running a server you most certainly want some form of security. HFS+ is not case sensitive. If you restrict certain files like "Hello" outsiders may be able to get to the same file by calling it "HeLlO" or "HELLO". UFS is case sensitive.

    OpenDarwin.org is looking into getting up-to-date UFS with FreeBSD and then maybe UFS2 from FreeBSD -current. I have been one of few people on the opendarwin.org list to respond and the exchange has been good about how to begin. Jordan Hubbard has provided good guidance.... now I just need the time and some help I am sure.

    If you are interested... please sign up.

    1. Re:Yes advantages by pudge · · Score: 2

      This does not mean UFS is more secure. Your example doesn't work anyway; I have a "private" directory on my Mac OS X web server, and Apache won't let me access it as "Private". Even if it did, you could use one of the *Match directives instead (which would be a pain, but thankfully, it's unnecessary).

    2. Re:Yes advantages by dadragon · · Score: 2, Informative

      Sure... but as you just commented it requires a special module.

      As I recall, the "special module" is included in MacOS X v10.1 (Server and Client) and it's in the Darwin source repository. It's not too difficult to come by, it just isn't in the apache master distribution.

      And anyway, it's just fine for people who are using it to host a personal site, and still be able to use their computer to run Mozilla and Quake. If I wanted to host a real site I wouldn't hesitate to use UFS.

      --
      God save our Queen, and Heaven bless The Maple Leaf Forever!
    3. Re:Yes advantages by Leimy · · Score: 3, Informative

      Actually, as far as I've experienced, HFS+ IS case-sensitive,
      You haven't done much then.

      [dave@tivo dave]$ ssh dleimbac@mac1
      dleimbac@mac1's password:
      Welcome to Darwin!
      mac1% cd /tmp
      mac1% ls
      mac1% touch Hello
      mac1% touch HeLLo
      mac1% ls -l
      total 0
      -rw-r--r-- 1 dleimbac wheel 0 Jun 14 13:14 Hello
      mac1%

    4. Re:Yes advantages by Leimy · · Score: 2

      synchronous is for guaranteed writes before a power out. Synchronous writes on FreeBSD are very fast. Sometimes it beat ext2 on linux [which had horribly dangerous async writes by default]. Its a matter of opinion that synchronous writes are better. They can be sped up by using Soft Updates for metadata. There is a lot of information about this stuff. Don't assume synchronous == horrible performance.

    5. Re:Yes advantages by 1010011010 · · Score: 2

      "Synchronous" does mean poor performance when it involves a slow mechanical system like a disk drive.

      Sync writes on BSD are not magic -- they have to wait the the disk mechanics to operate just like on other OSes.

      --
      Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
    6. Re:Yes advantages by Leimy · · Score: 2

      of course... But you can still do a better job of it.

    7. Re:Yes advantages by Leimy · · Score: 3, Interesting

      Well UFS with softupdates would be your friend then wouldn't it. :) I am in the midst of doing some of the research necessary to bring this to UFS on OS X. I have McKusick's USENIX paper in hand... an assload of source to look through and a good dose of coffee/tea [mood depending].

      So far one other OpenDarwinite and myself seem to be interested in making this happen + Jordan Hubbard [who probably just doesn't have the time to help much.]

      Dave

    8. Re:Yes advantages by 1010011010 · · Score: 2

      HFS and HFS+ are both in the "POS" category of filesystems. One big b-tree catalog file? Yuk.

      What Apple needs is XFS, or Reiser with Named Streams (or Extended Attributes).

      Or perhaps even UFS with softupdates and named streams support, plus a case-insensitive-but-case-retaining option.

      --
      Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
    9. Re:Yes advantages by softsign · · Score: 2
      The reason for this is that Apple includes an Apache module to address exactly that problem. When the original OS X was shipped (10.0.0, I think), this mod was missing and there was a gaping security hole. People could work around permissions just by addressing a file/folder differently than in the access file.

      Check it out, go into /etc/httpd/httpd.conf and look in the LoadModule directives. At the very end will be something like mod_hfs. This comes from Apple. Comment it out, restart Apache and you'll see that you can now use any case you want.

  4. ufs not for desktop usage by d0n+quix0te · · Score: 4, Interesting

    it is primarily to be used if you are running a web server. Apache is better tuned for UFS than HFS+.

    Use HFS+ if you are going to use it as a desktop. Many apps including Office will have problems because they expect a HFS+ system supporting Type/Creator info.

    1. Re:ufs not for desktop usage by SpamJunkie · · Score: 2, Informative

      UFS under Mac OS X does have type/creator info. It uses the AppleDouble hack that uses hidden files to store the mac resource fork.

      The main problem that desktop apps will have with UFS is its case sensitivity. Many apps expect to be able to ask for a file in any case and get a like-named but differently cased file.

      Personally, I would be surprised if any program as robust as Office had this problem.

    2. Re:ufs not for desktop usage by Duck_Taffy · · Score: 2, Informative

      Support for Meta data isn't the issue here - it's the fact that UFS doesn't support resource forks, which Carbon apps still contain. If you install a Carbon app on a UFS drive, your resource fork disappears.

      --
      Karma: Ran over your dogma.
  5. I use both at home by SandSpider · · Score: 3, Interesting

    I have UFS for my User partition, and all of the rest of my partitions are HFS+. The reason for this is that, if you boot in OS 9, all of your permissions are ignored, and anyone can waltz into your hard drive and play around. UFS isn't readable by OS 9, so no worries there.

    I haven't really had any problems with my setup. Maybe there are some things I'll find the more I use it, but I've had this setup for months, and I haven't really noticed anything. But I certainly wouldn't format my system partition UFS. I tried that once, and it didn't work for non-server use at all. Mostly because, if something went wrong with the hard drive, I didn't have a boot disc that could do anything about it. That probably isn't a problem with things like the new HD tool from Micromat, but at the time it was a pain.

    =Brian

    --
    There is nothing so good that someone, somewhere, will not hate it.
    1. Re:I use both at home by SandSpider · · Score: 2, Informative

      That's the thing; my system drive isn't UFS. I have 5 partitions: 1) OS9 - HFS+; 2) OSX - HFS+; 3) User - UFS; 4) Swap 1 - HFS+; 5) Swap 2 - HFS+.

      This way, the user data is protected, and all the apps work properly. Swap 1 is a system swap, and Swap 2 is for applications like Photoshop that have their own swap files.

      =Brian

      --
      There is nothing so good that someone, somewhere, will not hate it.
    2. Re:I use both at home by weave · · Score: 2

      Interesting, but couldn't someone still just boot into single user mode and get into all of your files? (I'm a unix geek and new mac owner. Is it even possible to do this? I thought I remembered doing it with some magic key combo, but can't remember if I was prompted for a password).

    3. Re:I use both at home by SandSpider · · Score: 2, Interesting

      This is very true. Single User Mode grants root privileges without requiring a password. Being able to reset the password with the OS X CD is also an issue, though one that can be worked around with the new Open Firmware password, I believe.

      Personally, I think there should be a secure option in OS X, that allows you to disable the various methods of password resetting. Of course, the clever and knowledgeable user will be able to bypass any of those, since there's always a way around security if you have physical access to the computer itself.

      Fortunately, my roommates are very rarely that knowledgeable about macs and unix. Also, I don't really have anything of import on my computer. I just never liked pretending to have security that could be defeated by booting into OS 9. It was the same in the pre-X days, where most of the security programs relied on people not having a standard boot floppy. It's just wasteful to have to be bothered typing in a password if the security is too easy to crack.

      =Brian

      --
      There is nothing so good that someone, somewhere, will not hate it.
  6. Re:CVS Ref... by Tsk · · Score: 3, Informative

    I do use cvs over ssh and it works (I used it for OpanDarwin).
    I then can ssh anywhere I want.
    The problem with CVSd is the case-sensitive issue that can be found in found in HFS.

    --
    none Yet.
  7. Do NOT install UFS by nachoman · · Score: 5, Informative

    I thought along the same lines... It is Unix, so UFS should be better... So, I formatted my iBook and went with UFS.

    I was wrong. All of the mac applications run much better under HFS. Things like Appleworks need an HFS partition so they work with OS 9 as well as X. And mozilla still won't run in a UFS partition. As of version 10.1.3 (not exactly sure which one I tried) there were still a LOT of problems with UFS. I got a lot of data corruption on my UFS partition. Also, disk IO seemed a lot slower than with an HFS partition. The system kept getting slower and slower.

    Finally, I reinstalled again with HFS. All of my troubles went away. In my opinion, don't use UFS unless you have a really important reason to do so.

  8. OS 9 & Classic by CokeBear · · Score: 4, Informative

    The most important reason to stick with HFS+ is that a UFS drive cannot boot back into OS 9, and does not support Classic. (Also, HFS+ is faster)

    --
    Reality has a liberal bias
  9. Re:Back in the day... by Pituritus+Ani · · Score: 2

    Nice SAT reference!

    --

    Another proud carrier of the $rtbl flag

  10. performances by patpro · · Score: 2

    in term of performances HFS+ is better than UFS. In fact, from the quick benches I've done with my FreeBSD's, HFS+ is faster than UFS, and slower than UFS+softupdates (witch is approximatively equivalent to ext2 FS in term of read-write perf.).

    Ones should definitively choose HFS+ for OSX, a secondary partition using UFS can be a good idea for UN*X addict, but is absolutely useless for everyday desktop use.

  11. Beware of UFS by siliconwafer · · Score: 2, Informative

    My advice: Do *NOT* use UFS on Mac OS X unless you are running a server. If you plan on using applications besides Apache or database software, use HFS+. I bought a new Powerbook several months ago and went with UFS, assuming it would be faster, superior, etc. I found that many programs (even Mozilla!) would not run on UFS. They'd simply crash or spit out strange error messages. After getting frustrated, I reinstalled using HFS+. I was *AMAZED* at the speed difference. It really is a lot faster: Apps load faster, file copying is faster, everything just seems more responsive. And, I no longer have trouble with software such as Mozilla, Toast Titanium, Dreamweaver, etc.

    The bottom line: Stick with HFS.

  12. Re:Why Not Port XFS by Tsk · · Score: 3, Informative

    it would seem relatively trivial to port XFS to the OS.
    There's a icensing issue Here. SGI'sxfs is GPLed, apple does not endorse GPL or LPGLed software. They removed wget because it was gpled, gnutar has also been removed. Apple want to use BSD like licence exclusively, so one day if they want to they can make a closed source OS again .....
    If you'de want xfs on OS X it should come from The GNU-Darwin project or from Fink. Both project are leading software port (one bringing support for AMD powered ia32 machines).

    --
    none Yet.
  13. Re:Back in the day... by ahknight · · Score: 3, Insightful
    Really, is it so hard to have data structures for file io that have more than 31 places for filenames?

    With 15 years of code under their belt that relied on just that fact, well, yes.

  14. UFS can be used, in its place by depeche · · Score: 4, Informative

    Apple includes UFS becuase all Cocoa applications will run correctly with UFS, and Carbon applications (if written correctly) will also run correctly. Apple uses its previously published standards (see Netatalk list archive for a discussion) to seperate the data and resource forks. The problem is that many MacOS applications--and the entire classic environment--require HFS compatibility. Many applications will not even install onto a UFS drive. If your environment is mostly Unix, and you are a developer or a web designer, having the same case-preserving, case-sensitive file system symantics that other Unix implementations may be a benifit. Otherwise, stick to HFS+. I, for one, have signed and recommend that other sign the Metadata petition which calls for Apple to move towarsd a modern file system which has multiple streams (as apposed to two fixed streams) and a generalized metadata implementation a la BeFS or Attributed FS to provide the core HFS compatible metadata with the ability to extend the metadata use into new areas. A journaled file system would also be a plus. HFS+ is a reasonably efficient and Unix like file system. The only difference is the case-preserving, case-insensitive file symantics, which is arguably (many discussions abound) is preferable for a GUI, and human UI in general.

    A big bonus would be implementing posix compliant multiple stream bsd userland commands like cp so that you don't axe your resource fork when you cp a file from the command line, etc.

  15. formatting as UFS by pretentiousb · · Score: 2, Informative

    When Mozilla 1.0 became available, I formatted my HD as UFS...I had been waiting and waiting to do this just to play around with it. Anyway, it turned out to be a BIG mistake. The first thing I installed was Mozilla. It installed fine, but when I tried to run it, it would quit before the launch was finished. The same happened with Netscape...I thought maybe it was just a "Mozilla-type" thing...I was wrong...I then tried installing MS Office (sorry I turned to Microsoft...I need the compatibility for school)...that installer wouldn't even run...it wouldn't give me permission to install on UFS formatted "/" So then, I reformatted back to HFS+. I reinstalled everything, and since, everything has worked fine...I have even installed mySQL and PHP, and both of them seem to work wonderfully as well. I'm not sure if this will help or not, but when I reformatted as HFS+, I named my HD "/" just like it would have been if I had formatted it as UFS. You may also want to check out the postings by SandSpider and Nachoman...they seem like they ran into problems similar to mine...one of them suggested (along with some others) that you partition the HD so you can have both a UFS partition and a HFS+ partition. Anyway, good luck!

  16. You want UFS? Here's a trick: by Anonymous Coward · · Score: 5, Informative

    I was trying to get UMN Gopherd running on my OS X box awhile back, and one neat trick that was suggested to me by the maintainer of the package that helped was to use the Disk Copy application to create a virtual UFS device. I dragged the files I wanted to compile into my virtual drive, cd'ed into it, did the make thing, and presto: it compiled beautifully. Even neater is that I could still install it into the standard hierarchy, which was hfs+ formatted, and it still ran just smooth.

    So my advice is this: format your drive hfs, and when you need to do a project that requires UFS, simplly create a big enough blank UFS drive using Disk Copy, and do your work in it. Talk about having your cake and eating it too!

    ...mmmm... cake.....

  17. case sensitivity as a security measure?! by Tumbleweed · · Score: 2

    That's the most idiotic reason for case-sensitivity I've ever heard. If someone has enough access to your system to get a file in one case situation, they've got enough access to get to anything else in the same directory.

    The fact is, I've never heard anyone come up with a good idea for case sensitivity. The only one anyone ever comes up with is, "Well, with case sensitivity, I can have a file named 'Hello' and one named 'HELLO', etc." Hello, that's not an advantage - it's confusing as hell!

    Case insensitivity with case-retention is the ideal - and that's what HFS+ has. If Apple would just fix their slow-ass hardware, I'd change over in a heartbeat (assuming I had the $).

    1. Re:case sensitivity as a security measure?! by 1010011010 · · Score: 3, Insightful

      Case-sensitivity is easy, as it's just comparing bytes. Case-insensitivity is hard for non-English (and the more non-English, the harder it gets) languages, because you have to search through a table of equivalent glyphs. It's a lot more overhead. Also, the Unix core of OSX doesn't use Unicode natively, which adds a layer of complexity.

      --
      Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
    2. Re:case sensitivity as a security measure?! by Tumbleweed · · Score: 2

      Okay, that's a reason. Not a great one, but it's a reason.

      Things that are complex and take time to do correctly are the reason computers were made in the first place. Shying away from such situations with computers is not the brightest thing I could think of. Doing so when there are benefits is REALLY not smart.

  18. Oh shit, someone else is out of alcohol! by Graymalkin · · Score: 2

    The problems of UFS and HFS+ and different types of software stem from the way they deliniate directories. HFS has always deliniated directories with a colon. Your Applications folder is SystemDisk:Applications and home is SystemDisk:Documents or whatever arrangement you have. UFS deliniates directories with a slash. Apple is working towards ditching HFS entirely so they can switch to a more Unix friendly file system when they finally drop support for Classic applications in OSX.

    In many cases Darwin project Ports and Fink packages work much better with a UFS partition than they do with an HFS+ partition because they contain absolute paths using slashes for directories rather than colons. Classic and some Carbon applications do the opposite, they use absolute paths with colons. Your best bet is to make an HFS+ partition for your Mac software and then a smaller separate UFS partition to mount as /opt or something. The default BSD tools work fine with HFS+ but third party stuff might not work as well so putting them on a separate partition you know they will work on might be your best bet.

    --
    I'm a loner Dottie, a Rebel.
  19. support ReiserFS by g4dget · · Score: 2

    OSX's HFS+ and UFS seem a bit antiquated, and they are a pain to read from other machines as well. It would be great if OSX could support ReiserFS. Ext3 would also be a reasonable choice.

  20. Re:Why Not Port XFS by 1010011010 · · Score: 3, Informative

    They still use GCC... but then, there are no BSD-licensed compilers.

    --
    Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
  21. Re:Hardcoded Path Names by Graymalkin · · Score: 2

    Maybe I am wrong about the colon/slash problem, when working on stuff that always seemed like the issue at hand. OSX is actually trying to get away from resource forks in the file system you'll notice too. Instead of the resource fork for a directory that information is being stored in a .PStores file in that directory. It stores pretty much the same information as a resource fork but can be used just fine on a non-HFS partition. The insitance that Finder write a .PStores file as well as a couple other files can be annoying when using NFS or SMB mounts on non-Unix systems.

    --
    I'm a loner Dottie, a Rebel.
  22. Myths and Facts, plus a suggestion by gseidman · · Score: 5, Informative
    First off, I see a lot of people posting about how UFS does not support resource forks. This is technically true, but false in practice. Any non-Classic application which reads or writes resource forks will work just fine on files stored on a UFS partition. Same with metadata (type/creator). While HFS and HFS+ associate the data fork with the hidden resource fork and metadata one way, UFS does it another. The resource fork and metadata are hidden and associated with the data fork by a naming convention rather than by an intrinsic aspect of the filesystem.

    Second, I cannot recommend UFS for a root partition. Too many installers rely on the root partition being HFS+. They give errors about not being able to install on a "network file system" (which should be possible regardless). I had my system set up with several UFS partitions and no HFS+ partition at all, and ran into problems trying to install a bunch of stuff I genuinely wanted. So I gave up and made my root partition HFS+.

    What I recommend, however, is that only the root be HFS+. My /Users partition is UFS. A couple of other partitions are UFS. I ordered an external FireWire drive and the several partitions I will be putting on it (including /Library, /Applications, and /Developer) will all be UFS.

    (For those who are worried about /Library being externally mounted -- I haven't figured out what difference Apple intends there to be between /System/Library and /Library since both seem to be used identically, but I have chosen to treat /System/Library as containing things central to the running system such as StartupItems and Extensions, and /Library to be things related to applications, such as Application Support and Fonts.)

    To maintain my various UFS partitions, I have an /etc/fstab and run fsck -p in the Disks StartupItem. I've been doing things this ways for months and it seems to work quite nicely. I will mention that I do not use any Classic applications, so having partitions (such as my home directory) visible from Classic is not a concern. YMMV.

    1. Re:Myths and Facts, plus a suggestion by am+2k · · Score: 3, Informative
      For those who are worried about /Library being externally mounted -- I haven't figured out what difference Apple intends there to be between /System/Library and /Library since both seem to be used identically
      /System is reserved for Apple and may be completely replaced after a system update (wiping all your changes away).
  23. HFS+ was designed for performance by Megane · · Score: 4, Insightful
    I think one problem people are having with the HFS+ vs UFS issue is they think "Well, I haven't seen this UFS thing before, and HFS+ has been around for a long time, so UFS must be newer, and therefore it must be better!" All this without understanding one thing about how either file system works.

    UFS was included for those few people who needed a real, genuine, Unix file system. It has the "real inodes" and the case sensitivity that Unix apps expect. But (as far as I know), directories are stored as files with a special attribute, all over the disk, just like the MS-DOS FAT file system does. It does things this way after all this time because that's the way Unix has always done things.

    HFS+, however, is an extension to HFS to give it a few extra things that it needed to become a serious file system. Stuff like support for volumes larger than 2G, really long file names, Unix file attributes, etc. HFS stores directories in a B-tree file. In other words, it uses a database. This is much more efficient than a bunch of scattered files and inodes holding directory information.

    Basically, if you don't know a specific reason why you need UFS, don't use it.

    --
    #naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
  24. My experience: don't do it by Euro · · Score: 2, Informative
    Wow. I just finished my reinstallation of OS X and this pops up on Slashdot. Anyway...

    I got myself a G4 as a workstation about six months back. Being new to both OS X and the Mac world, I chose to format my partitions as UFS. BAD move. A lot of software simply refused to work (Mozilla being an example) if started from an UFS partition. Others (like the Harpoon 3 Demo) worked if I did some tweaking. Since OS9 doesn't know anything about UFS volumes, I was deprived of Classic apps as well (not that I have really needed any, but anyway). All this was a pain in the ass, though. For a long time I thought the software I tried was badly coded, but soon realized that it was due to my partitions being UFS only.

    Today I finally found the time to repartition as HFS+ and everything works like a charm. Finally I have a decent browser instead of that Microsoft crap. :-)

    To summarize: don't do it, unless you really, REALLY, REALLY know what you are doing.

    Just my .02 €

  25. Re:Hardcoded Path Names by spitzak · · Score: 2
    Not quite right.

    At the API to the system level, the seperator is slash. At some point after you typed in the 15/06/02 filename, some library or app replaced all the slashes with colons. This is the filename that was passed to the system through the Unix API.

    Later on the shell used the Unix API to get the filename, and retrived the filename with the colons. The changes were made when the file was created, not when the shell listed it.

    You may be confused because the HFS probably (I don't know for sure) translates colons in the names back to slashes so that the disk image can be read by OS9, and translated them back when read. However you could make a filesystem that rot13 or otherwise mangled the filenames when storing, but that fact is totally invisible to a program that does not examine the actual disk blocks, so that fact can be ignored.

    I am disappointed to see Apple favoring slashes in names over colons. The OSX finder will translate slashes to colons and back again, while translating colons the user types into into dashes and not back again. I would prefer if they turned slashes into dashes and left colons alone. This current scheme messes up two letters instead of one, also allowing people to think they can put slashes into their filenames is going to mess them up when they try to make web pages (which Apple seems to be pushing...)

  26. Why you should use HFS+ by anarkhos · · Score: 2, Informative

    I've read all the usual arguments to use either UFS or HFS+, but the main reason I use HFS+ is it supports FileIDs. Thus Aliases don't break when you move or rename the original file. This is a huge human interface advantage.

    I also suspect iterating directories is faster with HFS+.

    I'm hopeful somebody will develop a better filesystem which also supports FileIDs. HFS+ has a couple problems like fragmentation and corruption when interrupted. However Disk Warrior and Plus Optimizer fix those problems.

    --
    >80 column hard wrapped e-mail is not a sign of intelligent
    >life
  27. Re:Why Not Port XFS by bnenning · · Score: 2

    Right, but gcc isn't integral to the OS; it's only installed if you install the developer tools (the same is true for gnutar, the base install has only the BSD tar). AFAIK there is no GPL software on a stock install of OS X, which is probably justifiable paranoia by Apple's lawyers.

    --
    How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
  28. HEAD vs head by nullard · · Score: 2

    One example of why cas is important. The http interface perl scripts 'HEAD', 'GET', and 'POST' get installed with a number of packages. The 'head' command is used for reading the first few lines of a file. I use 'last|head' to see who has logged in recently. After installing the perl mods, that command freaked. It took a while to realise that 'HEAD' had replaced 'head' -- forcing me to find a new 'head' from another system. I renamed 'HEAD', 'GET', and 'POST' be preceding their names with 'HTTP_'.

    --


    t'nera semordnilap