Up to Something

Read any post you like. Read any place you like. In 1994 it was "NTFS doesn't fragment by design, it never fragments". In the later 90's it was "ext3" or some other filesystem "doesn't fragment". Later, starting in 2000 - OS X doesn't fragment.

Windows

It started for me Windows in about 1994, and hit a sort of minor crescendo around 2002. I was speaking - ON THE PHONE - with Microsoft Technical Support. They were telling me about how fragmentation doesn't exist on NTFS, and that the new object linking would allow persistent data across an entire network. Whatever that means. NTFS not only fragments, but it HYPER fragments. There are some excellent write ups on this phenomena, but it underlines a few points. The first is that designing fragmentation proof systems is a process of revision, at least in part, and not necessarily all "design".

Unix Derivatives

Pearls of Wisdom dispensed at the tail ends of sanity constantly admonish n00bs that Mac or Linux won't fragment, even if of other platforms will. Old school boards and such used to offer identical advice to the WindowsNT crowd. The sad facts are in. EVERYBODY FRAGMENTS. It's a function of longevity, slowly growing files, LARGE files in general and use patterns with the disk. Filesystems fragment very rapidly when you start running out of space, and no matter how large the volume, space eventually gets exhausted.

Leopard

Leopard does well, but even it has limits. My 700mb Thuderbird inbox has well over 4000 file fragments. (I run out of space a lot). I have several .DS_Store files which have more than 3 fragments. If you have space, if it can be done fast and if it's under 20mb, Leopard will defrag most any file on the fly. That said, if you get low on space, make your computer extra busy, and then handle large files, you're doomed.

The unspoken dilemma

One of the things which Windows Defragmenters have taught us is the value of reorganizing the disk layout. I can't tell you if it's honestly that valuable, but I can tell you if gives a warm fuzzy feeling.

There may be many ways and reasons which filesystems fragment, but they ALL fragment. People who tell you otherwise are clueless or stupid. The presence of software to defragment is nice and necessary for filesystem health. Get it. Love IT. USE IT. Profit.

_{This article is in response to all the clueless n00bs, drinking Apple's Koolaid and spouting ignorant stupidity as though it were lucid rational.}

You have to give Microsoft credit. They were 66% correct. That's about 150% better than normal. Seriously. Todays fun is imported from the land of broken-wmi-crap.

The Bug

After the super-exciting side affect of an asshat package manager, a Microsoft standard-issue-busted-software problem has cropped up:

Event Type: Error
Event Source: MSExchangeSA
Event Category: Monitoring
Event ID: 9097
Description:
The MAD Monitoring thread was unable to connect to 
WMI, error '0x8004100e'.

The Microsoft Article purported to fix this is 33% wrong. They list the major components, and the MSExchangeSA error does indeed subside. Side-note: I found that I had to re-do the steps listed in the TID - AFTER a reboot. ???

The Tragedy

However, I discovered a new pain after my joy: the Message Tracking Center returns WBEM error 0x80041010. Translate this, "missing wmi class". I did a number of searches (lots of hits from mis-informed TID-spouting 'do-holes) and finally located this article in Google Groups. He walks through re-creating WMI, and other neat things. I skipped ahead, as I had done all of this before.

I followed his testing advice - I couldn't get the remote testing to work - local testing showed that root\microsoftExchangeV2 only had 73 out of 74 classes. Frustrated I briefly considered a by-hand comparison with a functioning server. I chose to plow ahead, based on this guys informative nature and clear expertise - and it paid off:

The Missing Command

mofcomp.exe -n:root\cimv2\applications\exchange "c:\winnt\system32\wbem\msgtrk.mof"

In my case the command was actually:

mofcomp.exe -n:root\cimv2\applications\exchange msgtrk.mof

The Apathy

This worked when Microsoft Failed. I feel semi-indifferent. I think this is Microsofts chief tactic for dealing with "haters who want stuff that works". Entropy from the titanic marketing efforts makes the efforts get them to change them almost worthless.

As a side note, I did submit feedback at the support site. Maybe someone will see it?

If you have to work in networks with any Windows products, coupled with MSDE or SQL Express you will eventually run into memory consumption problems. Apparently no GUI interface deals with it. I have seen numerous complaints on the Internet for sqlservr.exe consuming loads of memory. Some psychos recommend "uninstalling and re SBS Diva has a great article which I will here condense:

osql is the command-line tool for monkeying with MS-SQL200*.

c:\> osql -E -S MYSERVER\instancename
1>

So, first add the "Process ID" column to Task Manager. Note the PID of the offending SQL process. Next, open command prompt, and run tasklist /svc. Locate the PID matching the process, and find the name you want:

sqlservr.exe                  1972 MSSQL$SBSMONITORING
sqlservr.exe                  2020 MSSQL$SHAREPOINT

The part after the '$' is the instancename. (Hopefully you already know your machinename.)

Once you have the instance, run osql as shown above.

c:\> osql -E -S MYSERVER\instancename
1> sp_configure 'show advanced options',1
2> reconfigure
3> go
1> sp_configure 'max server memory',128
2> reconfigure with override
3> go

max server memory: this option is in megabytes. This will change the 'MSSQL$INSTANCENAME' to operate at 128 Megabytes. (When set this way, most of my instances reported between 160M and 180M when in use.)

Notes

It's simple to list all of the configured parameters for the server, simply load osql, as shown above, and run:

1> sp_configure 'show advanced options',1
2> reconfigure
3> go
1> sp_configure
2> go

That will dump all the configured options. It of course enabled advanced options.

.. or how to share folders from Windows 2003 with Macs via AFP/MacFile/File Services for Machintosh

I don't know what I missed, but this is the one type of sharing that requires using Computer Management.

Right-Click My Computer, Click Manage. Click on Shared Folders. From there you can right-click white space and use New Share to create new shares. The third screen in the dialog allows you to pick Windows, Mac or both.