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

Question

Я обновил Windows 7 до 10 Professional на твердотельном накопителе и создал соединения каталогов, используя командную строку 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: это жесткий диск (не съемный).

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

Answer 1

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.

Answer 2

Мне удалось решить эту проблему, отключив быстрый запуск в параметрах питания панели управления 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: