Why different kinds of shortcuts created with drag and drop?

Recently, I became aware that I had unwittingly created two different kinds
of folder shortcuts in my Favourite Links (C:\Users\<username>\Links) folder
in Windows Explorer. I noticed this after I created a new toolbar for the
folder in my taskbar, where clicking on the toolbar would bring up a
cascading menu of the folders in Favourite Links - most of which were
displayed as menus (with arrows next to them that would show the contents of
each folder in still another cascading menu), but the two most recent entries
I'd added were just simple folder links that would only open the folder in a
separate window.

When I looked at the contents of C:\Users\<username>\Links, I could see that
the last two folder shortcuts I had dragged into the folder were designated
as "shortcuts" while the first series of folders I had dragged there were
identified as "files"! (How could a folder shortcut be a "file," I wondered,
but these were the shortcuts that created the cascading menus in the taskbar
toolbar.)

I wanted all of the folders to appear as menus in the toolbar, so I wracked
my brain trying to remember what I did differently the two different times I
populated my Favorite Links folder. It took me a lot of trial and error
before I finally discovered that the different behaviour was dependent on
which key(s) I hold down when I drag a folder into Favourite Links.

If I drag a folder to Favourite Links holding down the <Alt> key (or by
right-dragging and choosing "Create Shortcut" from the pop-up menu), a
regular shortcut is created; if I, instead, hold down the <Ctrl> and <Shift>
keys simultaneously while I drag the item, the resulting shortcut is a "file"
with a cascading menu.

I can't remember where I learned these two different keyboard combinations
for creating shortcuts (both have stuck in my head for years, probably going
back to the days of Windows 3.1, or at least Windows 95), but I was never
taught that there was any difference in the kind of shortcuts they created.
I haven't been able to find any sort of documentation about this difference
anywhere and I was wondering if anybody knows more details about it, such as
what other types of objects (besides folders) are affected and in what ways
(basically, more about the intended purpose of the <Ctrl-Shift> method of
dragging).

Thanks.

I knew about Folder Shortcuts (which show as type 'Folder Shortcut' on my
comp - they showed as File a long time ago, maybe changed via update). But
the way I knew of creating them was right-clicking & dragging to the opened
Start Menu folder & opting for 'Create Shortcut' (something special about
that folder) and then moving it to the desired location. So thanks for the
<ctrl>+<shift> trick!

Here's what I do know. If you open a folder containing a Folder Shortcut
(FS from here on) and perform a 'dir' command, you'll see that the FS is
itself a directory. Change to that directory & perform 'dir /a' & you'll
see it contains two files: desktop.ini & target.lnk. Target.lnk is a
standard shortcut to a folder. The desktop.ini file contains the following:

[.ShellClassInfo]
CLSID2={0AFACED1-E828-11D1-9187-B532F1E9575D}
Flags=2

It's this info that tells Explorer to display the contents of the target of
the target.lnk shortcut, rather than the actual folder contents.

If you Google on the above CLSID value, you'll find plenty of discussion of
these.

If you remove the read-only attribute from the FS, you'll see the folder &
its two files in Explorer, as the read-only attribute is what tells Explorer
to process the desktop.ini file.

They really are handy, just try to avoid creating any looping references!

--
Good Luck,

Keith
Microsoft MVP [Windows Shell/User]



"PBear" <> wrote in message
news:A7B1980B-2DE9-4A00-A25C-...
> Recently, I became aware that I had unwittingly created two different
> kinds
> of folder shortcuts in my Favourite Links (C:\Users\<username>\Links)
> folder
> in Windows Explorer. I noticed this after I created a new toolbar for the
> folder in my taskbar, where clicking on the toolbar would bring up a
> cascading menu of the folders in Favourite Links - most of which were
> displayed as menus (with arrows next to them that would show the contents
> of
> each folder in still another cascading menu), but the two most recent
> entries
> I'd added were just simple folder links that would only open the folder in
> a
> separate window.
>
> When I looked at the contents of C:\Users\<username>\Links, I could see
> that
> the last two folder shortcuts I had dragged into the folder were
> designated
> as "shortcuts" while the first series of folders I had dragged there were
> identified as "files"! (How could a folder shortcut be a "file," I
> wondered,
> but these were the shortcuts that created the cascading menus in the
> taskbar
> toolbar.)
>
> I wanted all of the folders to appear as menus in the toolbar, so I
> wracked
> my brain trying to remember what I did differently the two different times
> I
> populated my Favorite Links folder. It took me a lot of trial and error
> before I finally discovered that the different behaviour was dependent on
> which key(s) I hold down when I drag a folder into Favourite Links.
>
> If I drag a folder to Favourite Links holding down the <Alt> key (or by
> right-dragging and choosing "Create Shortcut" from the pop-up menu), a
> regular shortcut is created; if I, instead, hold down the <Ctrl> and
> <Shift>
> keys simultaneously while I drag the item, the resulting shortcut is a
> "file"
> with a cascading menu.
>
> I can't remember where I learned these two different keyboard combinations
> for creating shortcuts (both have stuck in my head for years, probably
> going
> back to the days of Windows 3.1, or at least Windows 95), but I was never
> taught that there was any difference in the kind of shortcuts they
> created.
> I haven't been able to find any sort of documentation about this
> difference
> anywhere and I was wondering if anybody knows more details about it, such
> as
> what other types of objects (besides folders) are affected and in what
> ways
> (basically, more about the intended purpose of the <Ctrl-Shift> method of
> dragging).
>
> Thanks.
>

Thanks for the reply. Interesting information. But these shortcuts still
show up on my system as file type "File," not "Folder Shortcut." I followed
your directions and found the desktop.ini file contained in one of the
subfolders, whose contents was the CLSID citation, just as you said.

Now I understand about how these folder shortcuts work, but I'd still like
to know who came up with the <Ctrl-Shift> drag operation and if/where it's
documented (to see if there's a specific reference to its non-standard
behaviour with these kinds of shortcuts, differentiating it from the standard
<Alt> drag method).

Regards.

"Keith Miller (MVP)" wrote:

> I knew about Folder Shortcuts (which show as type 'Folder Shortcut' on my
> comp - they showed as File a long time ago, maybe changed via update). But
> the way I knew of creating them was right-clicking & dragging to the opened
> Start Menu folder & opting for 'Create Shortcut' (something special about
> that folder) and then moving it to the desired location. So thanks for the
> <ctrl>+<shift> trick!
>
> Here's what I do know. If you open a folder containing a Folder Shortcut
> (FS from here on) and perform a 'dir' command, you'll see that the FS is
> itself a directory. Change to that directory & perform 'dir /a' & you'll
> see it contains two files: desktop.ini & target.lnk. Target.lnk is a
> standard shortcut to a folder. The desktop.ini file contains the following:
>
> [.ShellClassInfo]
> CLSID2={0AFACED1-E828-11D1-9187-B532F1E9575D}
> Flags=2
>
> It's this info that tells Explorer to display the contents of the target of
> the target.lnk shortcut, rather than the actual folder contents.
>
> If you Google on the above CLSID value, you'll find plenty of discussion of
> these.
>
> If you remove the read-only attribute from the FS, you'll see the folder &
> its two files in Explorer, as the read-only attribute is what tells Explorer
> to process the desktop.ini file.
>
> They really are handy, just try to avoid creating any looping references!
>
> --
> Good Luck,
>
> Keith
> Microsoft MVP [Windows Shell/User]
>

I don't know if this helps in your research, but they appear to be of the
same type as 'Network shortcuts' created in the nethood folder

Start > shell:nethood

Create a folder shortcut there and you get a similar type of folder shortcut
as these 'semi-folders' containing a target.lnk and a desktop.ini, as Keith
mentioned - ie appearing as type 'File', but with PerceivedType of folder.

--
Jon


"PBear" <> wrote in message
news:F83A5662-7986-45F4-9D45-...
> Thanks for the reply. Interesting information. But these shortcuts still
> show up on my system as file type "File," not "Folder Shortcut." I
> followed
> your directions and found the desktop.ini file contained in one of the
> subfolders, whose contents was the CLSID citation, just as you said.
>
> Now I understand about how these folder shortcuts work, but I'd still like
> to know who came up with the <Ctrl-Shift> drag operation and if/where it's
> documented (to see if there's a specific reference to its non-standard
> behaviour with these kinds of shortcuts, differentiating it from the
> standard
> <Alt> drag method).
>
> Regards.
>
> "Keith Miller (MVP)" wrote:
>
>> I knew about Folder Shortcuts (which show as type 'Folder Shortcut' on my
>> comp - they showed as File a long time ago, maybe changed via update).
>> But
>> the way I knew of creating them was right-clicking & dragging to the
>> opened
>> Start Menu folder & opting for 'Create Shortcut' (something special about
>> that folder) and then moving it to the desired location. So thanks for
>> the
>> <ctrl>+<shift> trick!
>>
>> Here's what I do know. If you open a folder containing a Folder Shortcut
>> (FS from here on) and perform a 'dir' command, you'll see that the FS is
>> itself a directory. Change to that directory & perform 'dir /a' & you'll
>> see it contains two files: desktop.ini & target.lnk. Target.lnk is a
>> standard shortcut to a folder. The desktop.ini file contains the
>> following:
>>
>> [.ShellClassInfo]
>> CLSID2={0AFACED1-E828-11D1-9187-B532F1E9575D}
>> Flags=2
>>
>> It's this info that tells Explorer to display the contents of the target
>> of
>> the target.lnk shortcut, rather than the actual folder contents.
>>
>> If you Google on the above CLSID value, you'll find plenty of discussion
>> of
>> these.
>>
>> If you remove the read-only attribute from the FS, you'll see the folder
>> &
>> its two files in Explorer, as the read-only attribute is what tells
>> Explorer
>> to process the desktop.ini file.
>>
>> They really are handy, just try to avoid creating any looping references!
>>
>> --
>> Good Luck,
>>
>> Keith
>> Microsoft MVP [Windows Shell/User]
>>
>