Запуск зарегистрированного вспомогательного приложения mime

Question

Раньше я мог запускать локально установленное вспомогательное приложение, регистрируя заданный mime-тип в реестре Windows.Это позволило мне разрешить пользователям нажимать один раз на ссылку на текущую установку нашего внутреннего браузерного приложения.Это прекрасно работало в Internet Explorer 5 (большую часть времени) и Firefox, но теперь не работает в Internet Explorer 7.

Имя файла, переданное моей командной строке /open/command, не является полным физическим путем к загруженному установочному пакету.Параметр path, который мне передает IE, равен

"C:\Document and Settings\chq-tomc\Local Settings\Temporary Internet Files\
  EIPortal_DEV_2_0_5_4[1].expd"

К сожалению, это не преобразуется в физический файл при вызове FileExists() или при попытке создать TFileStream объект.

В физическом пути отсутствует подкаталог скрытого кэширования Internet Explorer для временных интернет-файлов "Content.IE5\ALBKHO3Q" чей абсолютный путь был бы выражен как

"C:\Document and Settings\chq-tomc\Local Settings\Temporary Internet Files\ 
  Content.IE5\ALBKHO3Q\EIPortal_DEV_2_0_5_4[1].expd"

Да, подкаталоги генерируются IE случайным образом, и это не должно вызывать беспокойства, пока IE передает полный путь к моему вспомогательному приложению, чего он, к сожалению, не делает.

Установка вспомогательного приложения mime не является проблемой.Он устанавливается / обновляется с помощью глобального скрипта входа в систему для всех более чем 10 000 пользователей по всему миру.Помощник mime вызывается только тогда, когда пользователь нажимает на внутреннюю веб-страницу со ссылкой на установку нашего приложения для настольного браузера.Эта установка возвращается с mime-типом "application/x-expeditors".Регистрация ".expd" / "application/x-expeditors" mime-тип выглядит примерно так.

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.expd] 
@="ExpeditorsInstaller"
"Content Type"="application/x-expeditors"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ExpeditorsInstaller]
"EditFlags"=hex:00,00,01,00

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ExpeditorsInstaller\shell]

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ExpeditorsInstaller\shell\open]
@=""

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ExpeditorsInstaller\shell\open\command]
@="\"C:\\projects\\desktop2\\WebInstaller\\WebInstaller.exe\" \"%1\""

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\MIME\Database\Content Type\application/x-expeditors]
"Extension"=".expd"

Я рассматривал возможность перечисления всех записей кэша IE пользователя, но я был бы обеспокоен тем, сколько времени может потребоваться, чтобы изучить их все, или тем, что я могу в конечном итоге найти более старую запись кэша перед текущей записью, которую я ищу.Однако заключенный в квадратные скобки суффикс имени файла "[n]" может быть уникальным ключом.

Я попробовал метод wininet GetUrlCacheEntryInfo но для этого требуется URL-адрес, а не виртуальный путь, переданный IE.

Я надеюсь, что существует функция оболочки, которая, указав виртуальный путь, вернет обратно физический путь.

Answer 1

Некоторые дополнительные меры, чтобы закрыть этот вопрос.

Оказалось, что реальная проблема заключалась в том, как я создавал дескриптор файла с помощью TFileStream.Я изменил, чтобы открыть с помощью fmOpenRead или fmShareDenyWrite это решило то, что оказалось проблемой с блокировкой файлов.

srcFile := TFileStream.Create(physicalFilename, fmOpenRead or fmShareDenyWrite);

Answer 2

Я полагаю, что подкаталоги, созданные IE, генерируются случайным образом, поэтому вы не сможете гарантировать, что он будет называться одинаково каждый раз, и проблема, которую я вижу с методом реестра, заключается в том, что он работает только тогда, когда файл все еще находится в кэше ... очистка кэша приведет к удалению файла, требующего еще одной установки.

Не лучше ли было бы установить этот помощник в данные приложения?

Answer 3

Я не уверен в этом, но, возможно, это может привести вас в правильном направлении:попробуйте использовать функции кэша URL-адресов из библиотеки DLL wininet: Найти firststurlcacheentry, FindNextUrlCacheEntry, Найти closeurlcache для перечисления и когда вы найдете запись, имя локального файла которой соответствует указанному пути, возможно, вы можете использовать Извлекать файл cacheentryfile чтобы восстановить файл.

Answer 4

Я использую аналогичную систему с браузером X-Appl для отображения веб-приложений WAML, и она работает отлично.Может быть, вам стоит взглянуть на то, как им удалось это сделать.

Answer 5

Похоже, что iexplore передает пространство имен оболочки "name" файла, а не имя файловой системы.

Я не думаю, что существует документированный способ передачи идентификатора элемента оболочки в командной строке - explorer делает это сам, но есть соображения маршалинга, поскольку идентификаторы элементов оболочки являются (указателями на) двоичными структурами данных, которые допустимы только в одном процессе.

Что я мог бы попробовать сделать, так это:1.Вызовите SHGetDesktopFolder, который вернет корневой объект IShellFolder пространства имен оболочки.2.Вызовите IShellFolder::ParseDisplayName, чтобы превратить указанное вам имя обратно в список идентификаторов элементов оболочки.3.Попробуйте IShellFolder::GetDisplayNameOF с флагом SHGDN_FORPARSING - честно говоря, такое ощущение, что мы только что прошли полный круг и вернулись к тому, с чего начали.Потому что я думаю, что именно этот API в конечном счете отвечает за возврат "неправильного" относительного пути к файловой системе.