>>The thing to keep in mind, in my opinion, is that once you are addressing disk space other than local drives, drive letters are at best a handy shorthand - the more accurate and (hopefully) unchanging notation would be the UNC notation.

>Sorry, I'll have to take the other side on this one. The reason being that we just changed server operating system versions. Among the things that changed were the volume name of the servers, which changed the way they're addressed. Had my applications not been setup to look for the drive letter path combination, there would have been many hours spent re-writing and debugging. As it is, I've had to do nothing to deal with the change over.

There are several solutions that could work here:

a) Pathing based on variable drive letter. In this case, the application needs to learn the relevant drive letter - I'd judge this the least effective.

b) Pathing based on absolute drive letter. Better, but you essentially marry that drive letter to that application.

c) Relative pathing - place application on server. Probably the most flexible, since no letter would be required at all - any good reasons not to do this?

d) Direct UNC (addressing volume) - very clean, only problem occurs if volume names are changed. The argument here would be - how often do you change (as opposed to add) volume names?

e) Mapped UNC (where UNC is acually resolved by a intermediary process) - a bit complex, but near bulletproof - this would resolve the changing volume name problem. However, if you're running a system this size, wouldn't you be using SQL Server?

Any comment?

>BTW, I grew up on the South Side, around the University of Chicago. And I sure could go for an Italian Beef right now. :-)

I'm about mid-north side, and the Italian Beef idea sounds good to me :)