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

1261
Binary Code

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

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

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

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

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

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

5

2 ответа на вопрос

1
Binary Code

PortableApps is causing the deletion of the junction but the problem lies within Windows rmdir command. According to this thread on PortableApps forum, all applications packaged in PortableApps format, rely on rmdir to remove any leftover folders that might be created by the portable application. rmdir can remove an empty folder, will provide an error if the folder is not empty, but when used against a junction it just deletes the junction itself.

Portable Applications that use the AppData\Roaming\Mozilla folder, remove the junction when closed. Such portable applications include Seamonkey, Firefox Developer Edition, Firefox, etc.

Currently there seems to be no solution or workaround to this problem from the PortableApps side. There is though one thing that can be done to prevent the junction from being deleted. Instead of creating a junction (mklink /j) we can create a symbolic link (mklink /d) and then edit NTFS permissions on the symlink, adding Everyone Deny Full. I came up with this solution after reading this SU thread.

0
Glenn Slayden

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

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

enter image description here

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

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

Кажется, что реальным виновником может быть chkdsk.exeсам, независимо от сценария запуска, «Быстрый запуск» или иным образом. Это правда - и просто продемонстрировать - что явный запуск chkdsk.exeна определенном томе NTFS, по-видимому, полностью удаляет все точки повторного анализа между томами. Или, по крайней мере, для тех, кто создан с использованием \\?\Volume\записи пути, и это все, что я когда-либо использовал для них, и, таким образом, все, о чем я могу сообщить здесь:

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

X:\foo> linkd bar \\?\Volume\baz

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

Похожие вопросы