Простите, но вы не имеете права знать, где данный файл ярлыка будет изображен в окне Проводника
Комментатор Gabe предложил, чтобы файл ярлыка содержал в себе бит, показывающий, что ярлык указывает на папку, чтобы ярлыки на папки сортировались с настоящими папками. "Это позволило бы им правильно сортироваться без дополнительных усилий, кроме тех, которые необходимы, чтобы увидеть его значок." (Комментатор Josh согласился, что " Соображения производительности здесь не применимы, потому как проводник в любому случае смотрит на указываемое, чтобы получить значок," тем самым отклоняя аргумент комментатора AndyC, что производительность может быть проблемой.)
Хорошо, для начала, ярлыки запоминают, является ли указываемое файлом или папкой, или как минимум являлось ли оно файлом или папкой на момент создания ярлыка: IShellLink::GetIDList + IShellFolder::GetAttributesOf скажут вам это, и даже больше, о том, на что указывает ярлык.
Но говорить, что тут не больше работы, чем та, что нужна, чтобы увидеть значок, значит упускать из виду некоторые нюансы о значках: Во-первых, вы не можете сортировать по значку, потому последствия получения неверного значка (или неполучения значка вовсе) чисто визуальные. Что? Вообще не получили значок? Да, хорошо, если файл был заархивирован на ленту, Проводник не будет заморачиваться отзывом файла только для получения его значка, а вместо этого будет использовать его стандартный типовой значок, или, если нет стандартного типового значка, стандартный значок документа. В конце концов, вы не хотите, чтобы просмотр папки в Проводнике отзывал бы все файлы с ленты. Это типа делает архивирование файлов на ленту бессмысленным.
Даже если Проводник решает получить значок, он исполняет эту операцию низким приоритетом и в фоновом режиме. Для сравнения, вы не хотите, чтобы решение о том, где объект появится в списке, принималось в низкоприоритетной фоновой задаче. Если вы захотите, то вы либо не будете ничего показывать, пока вся отсортированная информация не будет доступна (иными словами, ничего не показывать очень долгое время, возможно, всегда, если файл был заархивирован на ленту), или вы будете показывать все, но перемещать объекты по мере поступления лучшей информации. Ни то, ни другое не есть особо приятное дело для пользователя.
Более того, это означает, что то, где объект покажется при сортировке зависит от того, кто спрашивает. Если вы не имеете права на чтение файла ярлыка, то вы не имеете достаточных прав определить, ссылается ли ярлык на папку или нет, и в этом случае Проводник должен решить, куда помещать файлы "я не знаю". Пойдут ли они с не-папками по умолчанию? Или вы хотите третью категорию "я не знаю"? Независимо от вашего выбора, результат будет в том, что положение файла меняется в зависимости от того, кто спрашивает. "Ой, а куда делся этот файл ярлыка? А, вот он. Что здесь происходит? С компьютерами так сложно."
Комментатор Leo Davidson заметил, что определение того, ссылается ли ярлык на файл или папку, дешево, если ссылаемое есть локальный жесткий диск, который не был приостановлен, но это ужасная куча если. Это что, означает, что вы сортируете ярлыки на локальные жесткие диски, которые не приостановлены иначе, чем ярлыки на сетевые диски или ярлыки на диски, которые были приостановлены? А не покажется ли это странным пользователям? "Ой, куда делся этот файл ярлыка? Ага, вот он. Что здесь происходит? Почему этот файл ярлыка изображается в половине случаев в одном месте и в половине случаев в другом месте? С компьютерами так сложно."
Далее, даже если это ярлык, ссылающийся на локальный жесткий диск, который не был приостановлен, это все еще не означает, что вы можете определить, файл это или папка: ссылаемое может более не существовать. Операция разрешения рваного ярлыка откладывается до тех пор, пока ярлык не запущен, форма "ленивого вычисления", которая избегает совершения дорогой операции поиска до тех пор, пока результат не нужен на самом деле. Если вы хотите сортировать ярлыки в соответствии с атрибутами ссылаемого, вам будет нужно разрешать все рваные ярлыки, чтобы увидеть, куда было перемещено ссылаемое, и является ли оно файлом или папкой.
Хорошо, вы можете решить, что рваные ярлыки на самом деле рваные, и потому никого не волнует, что происходит? Но есть сценарии, когда почти все ярлыки рваные, и пользователь полагается на процесс разрешения для их исправления. Но вы уже это знаете. Если профиль меню "Пуск" мигрирует с одной машины на другую, все ярлыки рвутся, но, когда пользователь решает запустить ярлык, процесс разрешения правит их так, что они запускают правильную программу; это всего лишь занимает чуть больше времени первый раз.
Я подозреваю, что, когда Leo Davidson запускает программу, которая сортирует ярлыки на папки вместе с папками, и включает ссылаемое ярлыка в колонку описания "без заметного влияния на производительность", он не пробует запускать ее по серверу в другой половине мира со временем пинга 500ms. Если у вас есть папка со 100 ярлыками через сеть с задержкой 500ms, всего лишь сортировка объектов займет почти минуту. Если же у вас есть папка, полная файлов, заархивированных на ленту, оно будет еще хуже. Возможно, этот сценарий не важен для него, но он важен для многих людей. На самом деле, кто-то может сказать, что ребята из Проводника не уделяют достаточного внимания этим сценариям, потому что с каждым релизом Windows вы можете быть уверены, что эти люди отправляют потоки жалоб, что последняя версия Проводника стала еще хуже на их международной корпоративной сети, и что команда Проводника должна сделать небольшой редизайн, чтобы все стало не так плохо.