Fog Creek Software
Discussion Board




Drive letter issues plague Windows

" The problem was that the drives would move everytime we rebooted the machine, which is not something you really want happening on a SQL Server installation (or any other type of installation I can think of at the moment)."

http://weblogs.sqlteam.com/derrickl/archive/2004/05/05/1314.aspx

Oh, only when you reboot.  Well, we all know that Windows rarely requires a reboot, so I wouldn't even worry about it.

More proof that Windows is a poor choice as an enterprise computing platform.  What's the matter, your SAN doesn't like migrating drive letters?

SNT the evolution of RMS
Wednesday, May 26, 2004

I think a little careful reading of that shows that something else was changing the drive letters.

Simon Lucy
Wednesday, May 26, 2004

What works on the dev machines and even in beta testing doesn't always work in the real world.  Sounds like EDS missed this one.

Lou
Wednesday, May 26, 2004

Yep - reading the article and comments it looks like EMC wrote directly to the registry to change drive letters, but didn't do the job right.

If an application moves memory but doesn't update the pointer, do you blame pointers for crashing the app?

Philo

Philo
Wednesday, May 26, 2004

Actually, a properly configured installation of Windows server shouldn't need to be rebooted any more often that a Linux machine.

Basically, the need to reboot all comes down to what processes you are running on the machine, if you run buggy programs, then you'll end up needing to reboot from time to time, but if all you're running is SQL server than it shouldn't really be an issue.

Nice troll anyway.

Steve Barbour
Wednesday, May 26, 2004

I always loathed the whole concept of drive letters. A hindering, stinking leftover from CP/M days. Is there any  single reason to prefer it over Unix-like single, mountable directory tree?

Egor
Wednesday, May 26, 2004

"Actually, a properly configured installation of Windows server shouldn't need to be rebooted any more often that a Linux machine."

Absolute, utter, complete bullshit.

A properly configured Win machine may have decent uptime, but you WILL reboot that machine on a semi-regular basis.

* installing patches
* many software upgrades
* .NET framework requires a reboot
* MDAC upgrade
etc...

Our production win servers take more babysitting than our Linux machines, so deal - we do!

Sassy
Wednesday, May 26, 2004

Our production Linux box is never rebooted.  That's not say it doesn't have problems -- we've got some buggy software.  Every so often I have to go in a restart a few services for whatever reason (install a patch, resource leaks, etc).

Rebooting causes serious downtime, and since we administer the box remotely, it's also a little dangerous.

Almost Anonymous
Wednesday, May 26, 2004

Well, strangely enough, our production Windows servers take as much baby sitting as our production Linux server.

Neener, neener, neener.  :-P

Granted, your Linux boxes may be better behaved than ours, but our SQL boxes get rebooted on average about once every 4 months, as SQL is the only thing we run on them.

As a matter of fact, right now our SQL boxes have better uptime than our AIX box, but that's due to a flaky battery backup on the AIX box and a very flaky local electric company.  The battery has been replaced and the generator's in the process of being installed (just got the extra wiring closet built), so that issue should be resolved now as well.

Now, our Windows/Citrix servers on the other hand, get rebooted weekly, but they have a lot of crufty user programs running on them.

Steve Barbour
Wednesday, May 26, 2004

"Basically, the need to reboot all comes down to what processes you are running on the machine, if you run buggy programs, then you'll end up needing to reboot from time to time, but if all you're running is SQL server than it shouldn't really be an issue."

Exactly, as long as you're not running windows...  ;)


Seriously though, I'm waiting for database driven filesystems to become more common.  I don't want to have my file in a single folder if it releates to a handful of projects.  I'd love for it to be "associated" with various topics and for there to be a single file unless I tell it otherwise.

KC
Wednesday, May 26, 2004

>I always loathed the whole concept of drive letters. A hindering, stinking leftover from CP/M days. Is there any  single reason to prefer it over Unix-like single, mountable directory tree?

Gee, I also agree with the above!

I am also missing something real big here? Drive letters go back 20 years ago.

I cannot Imagine that someone is actually writing, or using drive letters to map out files, or any data on their computer. Especially server based stuff?

Heck, even when I link tables to back end ms-access database on my LOCAL pc, I use UNC path names and NEVER use drive letters anywhere!

This is issue is not about how bad drive letters are.

The only issue here is why in the world are people still using drive letters!

We can use them…but why?


Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com
http://www.attcanada.net/~kallal.msn

Albert D. Kallal
Wednesday, May 26, 2004

Albert you are about a thousand times more clued up than most Windows developers.  I know of a product from CA that is hard coded to put stuff on a c drive during install.  This works marvelous on our terminal server which doesn't have a c drive.  For real fun install the app from a terminal server session rather than the console where you have your local c mapped.  Then you get the pleasure of thinking things work when they don't.

Things like this is why Windows is not enterprise ready. 

Somebody else blamed someone EMC for not updating the registry correctly.  Do you really believe settings as criticl as these should even be stored in the registry?  We all know how the registry never gets corrupted.  Sakes!  What the hell is wrong with a simple text config file?

SNT the evolution of RMS
Wednesday, May 26, 2004

Well I wouldn't blame Windows for people that assume that drive C exists  (though I would blame MS for needing to put all system files in the same damn place).  Before you'd have software that assumed a Drive A existed and that it was a floppy.  Actually a courier company's software I brushed against recently had that kind of restriction.

You can bash the registry for lots of reasons, performance usually and the inability to automatically roll back, but to replace it with a text config file, or rather gazillions of text config files strikes me as being peverse.

Unless you like the *nix thing of having to remember where the config files are for a particular app or utility and whether they get run from init.d or some other cantilevered wedding cake of code.

Its a very good job that Linux is stable enough to not need rebooting but a very bad job that reconfiguring it can leave it as a quivering mass of instability.

As for UNC paths, yes its much better than drive letters, though it also relies on machine names which can change.  I assume Albert does something similar to myself in abstracting the path to some kind of registry entry (system wide or specific to the app), that maps the connection to the UNC.  But then in that case you can use drive letters as well, if you need.

Mind you, if I'm doing some back of the fag packet debugging I'm likely to dump text diagnostics to some file in C:\tmp. 

Simon Lucy
Thursday, May 27, 2004

I wish MS came up with a way to install drivers and other systemrelated files without rebooting. On Linux you can so why not Windows?

blaZ
Thursday, May 27, 2004

You can for some drivers.

John Topley (www.johntopley.com)
Thursday, May 27, 2004

Interestingly if you use a UNC path to your own machine, your workstation service will communicate with your server service, requiring both to be running (and paths to be appropriately secured from an externally accessible format). UNC is fundemantally borked because accessing a file via a drive letter differs from how it is accessed via UNC.

.
Thursday, May 27, 2004

It is fair to point out that windows is missing a root path name that you can specify without a drive. So, there are some shortcomings.

And, my comments about using UNC path names really only applies to any situation where a file or resource is going to be used from a network connection (this is still my rule I follow).

I am in with the camp that thinks that drive letters suck….


Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com
http://www.attcanada.net/~kallal.msn

Albert D. Kallal
Friday, May 28, 2004

Don't the path variables such as $temp$ or $windir$ or $system$ (can you still use that) ot $personal$ (for the default My Documents folder) help.

What amazes me is that there are still developers who don't bother to follow the Microsoft guidelines for installation. After all, they are decided by developers who know a hell of a lot more about Windows than they are likely to, and are probably a heck of a lot brighter as well.

Laziness, or some strange kind of misplaced rebellion. Yet they wouldn't ignore the rules about which side of the road ot drive on (unless they're from India that is).

Stephen Jones
Friday, May 28, 2004

Sorry $sysdir$ not $system$

Stephen Jones
Friday, May 28, 2004

*  Recent Topics

*  Fog Creek Home