Требуется код для сравнения путей к файлу или папке - профессиональный, корректный

дешифруй фразу 

а что тут дешифровывать? Две строки widestring, нужно их сравнить на эффективное равенство, то есть не указывают ли они на один и тот же файл.
С поддержкой любой кодировки, в какой только можно сохранить имя папки или файла в NTFS

Для Windows можно так:
Для линукса может не сработать - там файловые системы регистрозависимые.
Это писал на XE. Для 2006 нужно заменить функции и типы на аналогичные юникодные - под рукой щас нет старой дельфи...
Принцип основан на GetShortPathName - превращает имя файла в DOS 8.3 представление, которое не содержит национальных символов.

Для сравнения строк в Windows есть CompareString. Можно использовать её, либо любую обёртку к ней в Delphi. Специальной функции для сравнения имён файлов в Windows нет.

Потом, эквивалентны ли для вас пути C:\SomeThing\ и C:\Something\.\ ? И C:\Users\ и C:\Пользователи\ ?

P.S.


И которая работать не будет, если на диске короткие имена отключены или файловая система их не поддерживает.

P.P.S. В JCL есть несколько готовых функций для приведения файловых путей к каноническому виду/сравнению.

да, пролемка сложнее, чем кажется на первый взгляд
вот на ветка на stackOverflow, а оттуда на некий блог
согласно последнему функция GetFinalPathNameByHandle может здорово помочь, но она доступна только на Win6.0+
Если же делать вручную, то что сделать?



 Ну, насколько я понимаю, если мы будем использовать флаг NORM_IGNORECASE, то это не везде будет верно.
 Потому что регистр может иметь значение - даже на NTFS, не так ли?

Может GetFileInformationByHandle ? Сравнивая индекс и  серийник тома? Но будет ли работать на каталогах(а не на файлах)?



 а какие?

Верно. Очень редко это имеет значение. Но я же не говорил, что туда всегда надо передавать NORM_IGNORECASE. Если хотите это учитывать - параметры к функции надо менять.



JclFileUtils.pas, function PathCanonicalize(const Path: string): string;

Ну и вообще, среди PathXYZ много полезного.



Я про эквивалентность путей не просто так спросил. Как насчёт учёта hardlink? Путь 

C:\Users\Default\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Accessories\Windows Explorer.lnk

ссылается на тот же файл, что и:

C:\Users\Default user\Главное меню\Programs\Accessories\Windows Explorer.lnk

И это без учёта локализованных имён. А если их считать, то и этот путь будет ссылаться на тот же файл:

C:\Пользователи\Default user\Главное меню\Programs\Accessories\Windows Explorer.lnk

Добавлено через 4 минуты и 45 секунд
Можно посмотреть в сторону открытия обоих файлов и получения их ID (вычисляется на базе физического размещения файла на диске) через GetFileInformationByHandle:

Я сделал несколько тестов
Предложение Snowy с GetShortPath реализовал так:

оно не дает true на путях типа "C:\path\.\" и "C:\path\", но изменения регистра ей не помеха


Режется на изменении регистра, но не на "C:\path\.\" Это чисто строко-манипулирующая функция без валидации по отношению к файловой системе






GetFileInformationByHandle , когда ей даешь путь к файлу не режется ни на регистре, ни на '\.\'
c:\path\.\file.txt ==c:\pATh\.\fIle.txt
но когда я хочу сравнить папки, тут амба: открываю папки с флагом FILE_FLAG_BACKUP_SEMANTICS, и на любую папку выдает один и тот же индекс


вот сама песочница 

ну, если уж пошла такая п... - такой вопрос поднялся,  говорю, то да жесткие ссылки, символические ссылки, и даже там еще какие-то 6.0+ символические - и даже "Пространство имён оболочки Windows" , что бы это не значило...
Хотелось бы сделать раз и навсегда bullet-proof или около того