> > For me junctions are the best way to overcome having only 26 drive
> letters.
> > On a large network with lots of drives (including all the USB flash
> drives)
> > 26 is not enough. Using junctions gives me virtual pointers to remote
> drives.
>
> Just as a tech nitpick, and not to detract from the main point, but the
> target of what's commonly called "junctions" is limited to local drives.
> The equivalent for network drives would be "DFS links", but those require
> a server version of Windows to create/manage (with that available, yes,
> an entire LAN can technically be mapped under one drive letter, using a
> combination of local mount points and remote DFS links).
>
> Cheers,
> Liviu
Yes, you are correct. I was afraid this discussion would get lengthy and a bit off-topic, so my comments were a bit too brief to offer a full explanation. Also, the terms "junction" and "link" can be confusing and are sometimes used in a generic sense and I tend to refer to them all as junctions. For example, the mklink command can be used to create a junction (or a link).
I am constantly fighting a shortage of drive letters. I work with lots of servers that have lots of drives. I can not afford to map every drive on every server to a drive letter just so I can use it in ZTree. To mitigate this problem, when I set up a server, on the C: drive I create a folder that contains junctions that point to all the drives on that same server. To do that I create partition junctions using the mountvol command. They are junctions that point to a volume GUID. Then, in ZTree, when I connect to such a server I only have to use a single drive letter but I can access all the drives on that system as though they are folders under the C drive. The reparse points are processed on the server, not at the client. By the same token, to save drive letters, on my local PC I often use either junctions or symbolic links to point to other local drives. It's all about saving drive letters.
I sometimes fantasize that Kim will let us use a single numeric digit as a drive letter. Then we would create a table that maps the numeric drive letter to a UNC volume name. All file access would be done using fully qualified UNC names and drive letters would not be required. I know, I know, that's pretty far out but it illustrates how desperate I get for more drive letters in ZTree.
I won't go on -- this discussion could go on and on. But I agree with Laurent that it would sure help in ZTree to have create and delete commands for directory junctions.