C: vs. C:\ (OT)

#1
The notion of the current directory on a drive other than the drive containing my current directory hasn't meant anything to me in over twenty years. In fact I haven't even thought about it in that long.

I recently noticed (the hard way) that at least some C and Win32 functions still respect the difference between C: and C:\ (e.g., _wfullpath and GetFullPathName).

I was surprised to see (but understand):
Code:
v:\> echo %@truename[g:]
G:\TC15
 
v:\> echo %@truename[g:\]
G:\
I can't imagine capitalizing on that. Does anyone use this distinction to advantage?
 
#2
Most certainly I do many times a day! When you have multiple disk volumes (whether on a single system, or mapped through the LAN) containing identical directory trees / subtrees, updating (backup) is simplest if %@cwd[s:] and %@cwd[t:] match (i.e., each points to the root of the matching subtree of its respective drive), so you can just copy /s /uf s: t:.

BTW, the distinction dates back at least to PC-DOS 3. It is associated with the table PC-DOS maintained for all 26 drive letters of its current default directory, dropped in some old version of Windows, but which the JPsoft command processors do maintain. Thanks, Rex! Without such a table you'd have to spell out the two paths in full for copy etc.

The availability of the distinction in some Windows API-s makes it simpler to implement the distinction in a command processor.
 
#3
And I also do what Steve does on a regular basis. I would really hate for this capability/distinction to be taken away. Minor point: the directory trees from the root of the drive (X:\) may not be identical, but the trees are identical starting at the current directory on each drive and working on down.
 
#6
I vaguely recall that in Windows 98, it was global. So, if you had two copies of 4dos running and one changed the current directory on a drive, it would change for the other one. Rather dangerous.
I have no recollection of such malfeasance. It would affect not only 4DOS instances, but all programs. Say you are doing a wildcard move in one window, with implied specification of the source or target directory (using the table of current defaults for each drive) and another program changes one of them - your process would use the wrong source files or destination - you'd end with a real mixed up file system. However, the OS had its own copy of the table, and when a program was started, it inherited the current settings. And yes, there was an equivalent of today's SET /S: SET /M, but already running programs were not affected.