Defrag in OS X?

[hypocampers]

The editpost did not seem to work.

Getting back to defragmentation, why doesn't "fsck" work properly, "fsck" bog standard for all other UNIXs? Its a start and will give you an idea of how your disk is fragmented, the result is expressed in a %fragmentation

[strobe]

I hope Alsoft's OS X product (when it comes out) replaces Apple's fsck with their own. They have the best HFS+ tools.

UNIX interoperability is over-rated. I would rather have a filesystem which was more suitable as a human interface than a filesystem designed to be compatible with 30yr old crap. In fact the more Apple forges ahead instead of looking behind the better. The UNIX everything-is-a-file-at-a-static-path methodology really sucks and contrasts sharply with Mac OS since System 7.

In fact I would rather get rid of the filesystem altogether. That may break everything using POSIX file paths but that only makes the idea more appealing.

[hypocampers]

I hear you and agree in many respects (I really appreciate inovative behaviour), however we are going to be stuck with this stuff for some time.

Just one final point though, Unix's filesystem is no longer what it was 30 years ago, every vendor has its own SUN UFS (although I think SUN are moving to VFS), SGI XFS , veritas VFS, IBM, DEC, HP & Linux have their own specific versions and are mediated by NFS between platforms. The above are advanced filesystems, they look UNIXy as thats the user interface. But its what you don't see that critical, i.e. high availability, speed, distaster resistant etc (I would suggest that readers go to the vendors to get the specifics as they target different issues). One cannot take a disk from an SGI box, bung it into a SUN box and hope it will be read, the filesystems are very different.

[strobe]

All those filesystems share the same limitations which were created some 30yrs ago. For example the only way to refer to a closed file is by path.

HFS+ has limitations too. For example it can't support an arbitrary number of file attributes like I believe BFS can. However the major bottleneck in computing remains the human<->computer one and I'm far more efficient using HFS+ and periodically defragmenting using Alsoft tools than using UFS. Even the extra time required to port UNIX tools (which I have done on occasion) is small compared to the frustration of breaking aliases.

Unfortunately OS X is far eaier to break than MacOS because a lot of it uses the crappy UNIX methodology of everything-is-a-file-at-a-static-path. In MacOS I could move the System Folder anywhere I wanted. To make a bootable backup I just had to drag all my files from one volume to another, just one simple select and drag. Application updaters, including Apple, would look up an Application by its creator code, not its path. Now if you move an app you break the update mechanism. A lot of OS X apps also break if you move the file while it's being used! If you move a disk image while it's being verified it won't mount. If you move a TextEdit document while it's open TextEdit will lose track of it. Everything breaks so easily it's ridiculous!

In MacOS (since System 7) things were a lot easier. You didn't have to keep track of what files were open by which apps because the path of a file was considered variable. In many (or most) OS X apps the opposite is true so you have to keep track of all open files. If I move or rename a file or folder or non-root volume I have to check if there are any crappy apps running. Thus the advantage MacOS had is quickly lost when some OS X apps behave in an inferior manner.

[hypocampers]

No what you are talking about is emulation, not what is really happening as a
reality of a UNIX filesystem. see further comments bellow.

Also take a look at this page just to give you a flavour:

www.cabernet.demon.co.uk/XFS.html

www.cabernet.demon.co.uk/xfs2.html

Thats just a few snippets from SGI.

UNIX filesystems DON'T' share the same limitations as they implement their own FS, its the UNIX tools provided that cause the perception problem your running into. These problems are compounded by Apple not taking care of the UNIX it relies on. I bet you Apple has real working versions of UNIX backup that work, but if implemented would give vendors no place to sell anything.

UNIX vendors provide extra command sets to make available to the user the extended benefits of their filesystems, i.e Logical volumes, growing filesystems

For small or semi single user systems, arbititrarily moving system and data files around the system and still have it working is is fine, but in the end you have to go looking for them using FIND. However for terabytes of data and hundereds of users, stuff will be unmanageable.

As I said the REAL filesystem, that the vendors put out, underneath is wholey different and can be made to do almost anything, those attributes are used by companies like ORACLE, Sybase, high availability systems to maximize product performance. VFS is a good example, in that Veritas sell a filesystem for UNIX vendors. I've been saying this for well over a year on this bulletin board about the fact that Apple only attend to a small portion of UNIX before it takes you no further. Hence there was a "restore" but no "dump" in 10.0, crackers!, there were as host of other missing bits and pieces.

The moving of files around the system and being kept track of is software based, i.e. in MAE (macintosh Application Environment) this was all emulated quite happily, whilst running on a SparcStation under its UFS filesystem, it was the MacOS writting what it needed using UFS, Aliases worked fine, moving the the

Applications folder worked fine whilst using the Aliases under Solaris 2.x. What didn't work was moving /dev into /tmp via MAE, Solaris died instantly.


Apple could quite easily make a version of "dump" and "restore" that worked properly, each of all the other UNIX vendors DO for their extended filesystems.

"dd" should work as it copies the platter, i.e. dd if=/dev/disk1 of=/dev/disk2,the formatting and partitions as well, its slower as it copies all blanks space as well.

CPIO is POSIX compliant, Apple implement it (its supposed to work!), I wonder if it does work?

What it is your looking at under UNIX, i.e. command line executables will present UNIX information that has been interpreted for you in the accepted manner as outlined in "man", the filesystem underneath is completely different and can do many other things.

Remember UNIX is not in reality CODE but, an emulation of, services provided. I could go and write a UNIX, over the next 12 hundered years, that has code which bears no resemblance to anybody elses but woudl bee accepted as a UNIX. Ok there is BSD which you can download and System V which you would have to license, but the code is no where near the same.

Windows NT could quite happily considered a UNIX if it were to change the interface and access to the services which a UNIX is supposed to serve. This is public domain info. But you would'nt know at the end of the day, that you were actually using a MicroSoft product. Do you see what I am getting at, lots of people make the same assumption, but its only a fraction of the story.

Same with UNIX filesystems, they are in reality completely capable of being used in any mode you wish, its just that the standard set of UNIX commands always produce the standard interpretation of the filesystem, thats what they are meant to do. Thats why SUN have a UFSDUMP and SGI have a XFSDUMP, which dump entire filesystems properly even all the extended functionality underneath which the user doesn't normally see, the admin can detect the difference. Why didn't a HFSDUMP ever get made (I thougt there was one once), for a standalone system buying a product is nonsense, for truly big systems a purchased standlone solution won't cut it, you have then to move to NetBackup or Legato for corporate solutions.

Case insensitivity is just plain "BAD", fix the basics first. "System.txt" is the same as "system.txt". Having multiple copies around a system.....well I'll let you work the simplest example (in this case an Alias would have to keep an absolute path), connect this to other servers, NT, SUN, SGI, HP, DEC, Linux is going to be a heap problems that you can't fix.

Connecting to and NT domain (which will happen at work), NTFS is case sensitive, having System.Txt" or/and "system.TXT" on that server as well will give you the wrong file!. I said all this from the start 10.0, they've fixed some of of it but Apple has a way to go with its filesystem.

I'm going on way to long, I may have explained or pointed out some things, but solved nothing, Apple have to do it.

[Scottish]

Originally posted by plastic
For me, I use the good old copy, erase method. I have had bad things happening to my drives with defragmentation software. Nothing beats cleaning up the platters the good old formatting way. This is why I love Mac. Tell a PC dude to got format his hard disk and most likely he will give you the finger.

It's just as easy to backup your files to another hard drive and then format your primary hard drive on a PC as it is on a Mac. Am I missing something?

Scottish

[Javintosh]

He's referring to copying your System Folder. On OS9 a Mac you can copy your System folder to another hard drive (via drag and drop) and have absolutely everything preserved.

I won't think that you can drag your winnt folder to another drive and have everything work flawlessly.

[Scottish]

Originally posted by Javintosh
He's referring to copying your System Folder. On OS9 a Mac you can copy your System folder to another hard drive (via drag and drop) and have absolutely everything preserved.

I won't think that you can drag your winnt folder to another drive and have everything work flawlessly.

I have two issues with this: 1) I don't use OS9, and neither will any new Mac user after the first of the year. 2) I'd prefer to just backup my files that don't affect the system (music, documents, etc.) and give my hard drive an entirely clean slate. Half the time the problems are located in the System folder.

Scottish