Соединение каталогов продолжает удаляться

Я обновил Windows 7 до 10 Professional на SSD и создал соединения каталогов, используя командную строку mklink /Jдля папок, таких как игры, профили Mozilla и т. д., указывающих на каталог жесткого диска. Все соединения работают хорошо, за исключением профиля Mozilla Firefox, который связан так:

Junction created for C:\Users\[USERNAME]\AppData\Roaming\Mozilla <<===>> H:\Users\[USERNAME]\AppData\Roaming\Mozilla

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

Я также попробовал символьную ссылку на каталог (mklink /D), но происходит то же самое. Интересно, что у меня нет проблем с другими соединениями в том же объеме H:

Нет проблем с разрешениями и объемом NTFS H: фиксированный жесткий диск (не съемный).

Есть идеи, что вызывает это?

2 ответа

Решение

PortableApps вызывает удаление перекрестка, но проблема заключается в Windows rmdir команда. Согласно этой теме на форуме PortableApps, все приложения, упакованные в формате PortableApps, полагаются на rmdir удалить все оставшиеся папки, которые могут быть созданы переносным приложением. rmdir может удалить пустую папку, выдаст ошибку, если папка не пуста, но при использовании против перекрестка она просто удаляет сам перекресток.

Портативные приложения, использующие AppData\Roaming\Mozilla папку, удалите соединение, когда закрыто. К таким переносимым приложениям относятся Seamonkey, Firefox Developer Edition, Firefox и т. Д.

В настоящее время, похоже, нет решения или обходного пути для этой проблемы со стороны PortableApps. Есть, однако, одна вещь, которую можно сделать, чтобы предотвратить удаление соединения. Вместо создания перекрестка (mklink /j) мы можем создать символическую ссылку (mklink /d), а затем отредактируйте разрешения NTFS для символической ссылки, добавив Every Deny Full. Я придумал это решение после прочтения этой ветки SU.

Мне удалось решить эту проблему, отключив быстрый запуск в параметрах питания панели управления Windows 10. Трудно найти; ищите "Изменить то, что делает кнопка питания" в левом поле панели управления старой версии. После того, как он найден, он утверждает, что подан в:

Control Panel > All Control Panel Items > Power Options > System Settings

Чтобы было ясно, кажется, что в последних выпусках Windows 10, chkdsk.exe срабатывает во время определенных сценариев перезапуска (?). В моем случае это, в свою очередь, привело к массовому удалению всех моих постоянных, установленных вручную многотомных точек повторной обработки NTFS ("соединения каталогов").

Значение по умолчанию для быстрого запуска было изменено на "включено" в обновлении Creators 1709, которое, по крайней мере для моего случая, может объяснить, как возникла ранее невидимая проблема. Смотрите здесь для получения дополнительной информации.

Кажется, что настоящий виновник может быть chkdsk.exe Сам, независимо от сценария запуска, "Быстрый запуск" или иным образом. Это правда - и просто продемонстрировать - что явно работает chkdsk.exe на определенном томе NTFS, кажется, полностью удаляются все точки повторного анализа между томами. Или, по крайней мере, для тех, кто использует \\?\Volume{a6f7f7de-091e-4234-81a0-947ebba1bf3c}\ запись пути, которая является всем, что я когда-либо использую для них, и таким образом все, о чем я могу сообщить здесь:

Создать перекрестную жесткую ссылку, например

X:\foo> linkd bar \\?\Volume{ce775273-ab33-47af-8fac-1abdb60a0690}\baz

Это устанавливает жесткую связь между томами ("соединение" или "точка повторной обработки NTFS"), где X:\foo\bar перенаправлен так, что он равен каталогу \baz на указанном томе, но такие ссылки будут удаляться всякий раз, когда chkdsk.exe впоследствии запускается на исходном томе NTFS X:

Другие вопросы по тегам