Logfile ntfs как отключить

Сообщения: 3
Благодарности: 0

На ноутбуке вылезла такая проблема — почти постоянно загружен жесткий диск процессом System из-за чего такие микролаги, что подергивается курсор постоянно и при наборе текста пропускаются нажатия клавиш даже. Проблема не всегда, бывает отпускает, но не на долго.
Причем если включить приложение, которое обращается к жесткому, то в списке процессов начинает показывать что именно это приложение грузит жесткий диск и проц, особенно заметно со скайпом, пользоваться просто невозможно, загрузка жесткого 100%. С хромом по-проще, нагрузка на хард подскакивает но потом отпускает. В интернете очень большое количество аналогичных жалоб и чуть ли не на чистой системе и новом ноуте. Но решения проблемы так и не нашел. Многие говорят что после какого-то обновления такое появилось. Некоторые откатывались на Win7 и проблема уходила полностью.

До недавнего времени думал что проблема касается только моего ноута, но тут на пк решил переместить файл подкачки с ssd на обычный хард и началось что-то похожее, но в менее выраженной степени, т.к. пк достаточно шустрый. Очень заметно микролаги были выражены в играх, в bf4 к примеру раньше был фпс 50-80, но после переноса файла подкачки на другой хард, фпс каждые секунд 5-10 проседает до 2-3 на долю секунды. После переноса файла подкачки на ссд проблема уходит, специально проверял несколько раз. Хард новый.

На ноутбуке индексацию отключил, файл подкачки отключал вообще — не помогает.
На пк процесс System постоянно ПИШЕТ на диск, одновременно выполняя кучу задач, в каждой что-то связанное с логами.

System 4 C:\$LogFile (Журнал тома NTFS)
System 4 C:\Windows\System32\sru\SRU.chk
System 4 C:\$Mft (Основная таблица файлов NTFS)
System 4 C:\Users\Username\ntuser.dat.LOG1
И так далее, каждый процесс постоянно пишет на хард, хотя и скорость не большая. Может конечно проблема и не в этом.

Unformat для NTFS

На самом деле процесс форматирования протекает намного сложнее, но не будем в него углубляться – мы же не форматер пишем!

Интересующиеся могут взять в руки IDA Pro и расковырять format.com самостоятельно. Подсказка – format.com содержит лишь высокоуровневую надстройку, опирающуюся на библиотеки ifsutil.dll, untfs.dll и… непосредственно сам драйвер файловой системы. Так что дизассемблировать придется много.

Чтобы упросить себе работу, можно пронаблюдать за процессом форматирования с помощью шпионских средств – утилит Марка Руссиновича FileMon и DiskMon, бесплатные копии которых можно скачать с www.sysinternals.com. Также не забывайте о точках останова на основные native-API функции такие, как NtFsControlFile, NtDeviceIoControlFile и т. д. Да будет soft-ice вам в помощь!

Рисунок 2. Исследование процесса форматирования

Автоматическое восстановление отформатированного диска

Форматирование не уничтожает файловые записи пользовательских файлов, и они могут быть полностью восстановлены. Спасением данных занимается множество утилит (R-Studio, EasyRecovery, GetDataBack и т. д.), однако прямых наследников unformat среди них как-то не наблюдается. Unformat восстанавливал весь том целиком, а эти всего лишь «вытягивают» отдельные уцелевшие файлы/каталоги, переписывая их на новый носитель. Да где же нам его взять?!

Запись на оптические накопители отпадает сразу – во-первых, для сохранения 80-120 Гб жесткого диска в лучшем случае потребуется грузовик (на чем еще вы перевезете такое количество болванок?), во-вторых, непосредственная запись CD-R/RW не всегда возможна, ведь при крахе системы восстанавливающие утилиты приходится загружать с CD-ROM, а в большинстве компьютеров установлен только один оптический привод, и, в-третьих, ни одна известная мне утилита не позволяет «разрезать» большие файлы на несколько маленьких. Можно, конечно, перегнать данные по локальной сети (а она есть?) или установить дополнительный винчестер (корпус компьютера не опечатан, имеются свободные каналы контроллера и лишняя наличность в кармане). Но не слишком ли это хлопотно? Тем не менее для «вытягивания» пары сотен особо ценных файлов такая методика вполне подходит.

Продемонстрируем технику автоматического восстановления данных на примере утилиты R-Studio от компании R-TT Inc (www.r-tt.com). Это довольно мощный и в то же время простой в управлении инструмент, на который можно положиться. После запуска утилиты мы сразу попадаем в окно «Drive View», где перечислены все физические устройства и логические разделы. Находим среди них «свой» и, нажав правую клавишу мыши, говорим «Scan».

Нас запрашивают: начальный сектор для сканирования (start), по умолчанию равный 0, – оставляем его без изменений. Размер сканируемой области (size) по умолчанию развертывается на весь раздел. Это гарантирует, что сканер обнаружит все уцелевшие файловые записи, хотя сам поиск займет значительное время. Можно ли ускорить этот процесс? Давайте подсчитаем. Допустим, восстанавливаемый раздел содержит сто тысяч файлов. Типичный размер файловой записи составляет 1 Кб. При условии, что $MFT не фрагментирован, достаточно просканировать всего ~100 Мб от начала раздела. Если эта величина не превышает 10% полной емкости тома (размер пространства, зарезервированного под MFT) и диск никогда не заполнялся более чем на 90%, то, скорее всего, все так и есть. В противном случае $MFT наверняка фрагментирован и живописно разбросан по всему диску. Впрочем, в случае ошибки мы ничем не рискуем. Вводим N Кб, где N – предполагаемое количество файлов (каталог также считается файлом) и выполняем сканирование – если один или несколько файлов останутся необнаруженными, возвращаемся к настройкам по умолчанию и повторяем процедуру сканирования вновь (если количество имеющихся файлов заранее неизвестно, вводим 10% от емкости тома). В поле File System выбираем файловую систему NTFS, сбрасывая галочки напротив двух остальных (FAT и Ext2FS), т.к. они нам ни к чему, и нажимаем «Scan».

Рисунок 3. R-Studio осуществляет поиск уцелевших файловых записей

В процессе сканирования будут найдены все уцелевшие файлы (как удаленные, так и нет) и восстановлена структура директорий по корневой каталог включительно. Постойте! Как же так?! Ведь при форматировании он был уничтожен и сформирован заново! Файловую систему NTFS можно уничтожить только динамитом. Как уже отмечалось, в отличие от FAT, в NTFS каталоги являются лишь вспомогательной структурой данных, проиндексированной для ускорения отображения их содержимого. Всякая файловая запись независимо от своего происхождения, содержит ссылку на материнский каталог, представляющую собой номер записи в MFT. А запись корневого каталога всегда располагается по одному и тому же месту!

Удаленные файловые записи могут ссылаться на уже уничтоженные каталоги. R-Studio складывает их в папки вида $$$FolderXXX, где XXX – порядковый номер директории. Иерархия подкаталогов в большинстве случаев успешно восстанавливается.

Просмотр виртуального дерева обнаруженных файлов осуществляется нажатием кнопки или через одноименный пункт контекстного меню. Выбрав файл (или даже целый каталог с кучей подкаталогов), жмем или залезаем в предварительный просмотр/редактирование (пункт edit/view контекстного меню). Это достаточно мощный инструмент, отображающий внутреннее содержимое восстанавливаемого файла со всеми его атрибутами, списками отрезков и т. д. в «очеловеченном» формате, хотя до NT Exploder ему ох как далеко. При желании можно восстановить все файлы за раз («Recovery All») или выбрать восстановление по маске (Mask).

Рисунок 4. Восстановленная структура директорий

Рисунок 5. Красивый интерфейс Easy Recovery – компенсация за низкое качество восстановления

Хваленный Easy Recovery от Data Recovery Software вопреки своему названию простотой управления отнюдь не отличается и имеет довольно специфические особенности поведения. С настройками по умолчанию никаких файлов на отформатированном разделе он не увидит, и чтобы заставить этого зверюгу заработать в Advanced Options (дополнительные опции), необходимо указать Ignore MFT (игнорировать MFT), но и в этом случае качество восстановления будет оставлять желать лучшего.

Ручное восстановление отформатированного диска

Нашей целью будет ручное восстановление всего отформатированного раздела без использования дополнительных носителей информации и дорогостоящих утилит от сторонних производителей. Все, что потребуется, – это любой редактор диска (предпочтительнее всего, конечно же, NT Explorer от Runtime Software, но, на худой конец, сойдет и бесплатный Disk Probe/Sector Inspector от Microsoft) и chkdsk.

Очевидно, что в процессе форматирования происходит необратимое разрушение большого количества ключевых структур данных, восстанавливать которые вручную было бы слишком затруднительно. Да это, собственно, и не нужно! Идея состоит в том, чтобы вернуть разделу потерянные файловые записи, а все остальные ремонтные работы поручить chkdsk – пускай старается.

Дизассемблирование показывает, что единственной структурой данных, без которой не может работать chkdsk, является атрибут $DATA файла $MFT. А раз так, все, что нам надо – воссоздать прежний $MFT:$DATA, разместив его поверх старых файловых записей. В простейшем случае (если $MFT:$DATA не фрагментирован) это достигается спекулятивным увеличением его длины. А как ее увеличить?

Рисунок 6. Ручное восстановление MFT. Подчеркнуты поля, подлежащие изменению

Запускаем NT Explorer, переходим в начало MFT («Goto –> Mft»), щелкаем по $MF-файлу, находим атрибут $DATA (80h) и увеличиваем поля Allocated Size/Real Size/Compressed Size на требуемую величину, параллельно с этим корректируя список отрезков (он же run-list). Поле Last VCN трогать не нужно – chkdsk исправит его и сам. Как определить длину не фрагментированного MFT-файла? Она равна разнице номеров первого и последнего секторов, в начале которых присутствует сигнатура «FILE», умноженная на 512 байт (исключая сектора, принадлежащие $MFTMirr). Известные мне дисковые редакторы не поддерживают поиска последнего вхождения, поэтому соответствующую утилиту приходится писать самостоятельно. Впрочем, точную длину MFT определять совершенно необязательно и вполне допустимо взять ее с запасом – лишнее все равно отсеет chkdsk. Действуйте по принципу – лучше перебрать, чем недобрать.

Коварный NT Explorer не позволяет редактировать поля в естественном режиме отображения, заставляя нас переключаться в HEX-mode и искать смещения всех значений самостоятельно. Найти заголовок атрибута $DATA очень просто – в его начале расположена последовательность 80 00 00 00 xx 00 00 00 01. В NTFS версии 3.0 она находится по смещению F8h от начала сектора. Поле Real Size во всех версиях NTFS располагается по смещению 30h относительно заголовка, а поля Allocated Size и Initialized Size соответственно по смещениям 28h/38h байт, причем значение Allocates Size должно быть кратно размеру кластера.

Кстати, о кластерах. Убедитесь, что при переформатировании диска размер кластера не изменился, в противном случае у вас ничего не получится. Как восстановить исходный размер кластера? Да очень просто – набраться мужества и переформатировать восстанавливаемый диск с ключом /A:x, где x – размер кластера. А как его определить? Возьмем любой файл с известным содержимым и проанализируем его run-list. Пускаем контекстный поиск по всему диску, находим файл, запоминаем (записываем на бумажке) его стартовый сектор, после чего открываем закрепленный за ним FILE Record, декодируем run-list и вычисляем номер первого кластера. Делим номер сектора на номер кластера и получаем искомую величину.

Теперь необходимо сгенерировать новый run-list. В общем случае он будет выглядеть так: 13 XX XX XX YY 00, где XX XX XX – трехбайтовый размер $MFT в кластерах, а YY – стартовый кластер. Стартовый кластер обязательно должен указывать на первый кластер MFT, в противном случае chkdsk не сможет работать. Если новый run-list длиннее нынешнего (а именно так скорее всего и будет), необходимо скорректировать длину атрибутного заголовка (она расположена по смещению 04h от его начала). Проделав эту нехитрую операцию, запустим chkdsk с ключом /F и блаженно откинемся на спинку кресла, созерцая, как возрождаются наши милые папки и файлы. Единственное, что не восстанавливается – так это дескрипторы безопасности: всем файлам/папкам назначаются права доступа по умолчанию. В остальном же с отремонтированным диском вполне можно работать, не опасаясь, что он рухнет окончательно. Файлы, ссылающиеся на несуществующие каталоги, складываются в папку Found.xxx. Это «долгожители», пережившие несколько циклов переформатирования, в буквальном смысле вытащенные с того света.

Сложнее восстановить том, чей MFT сильно фрагментирован. Прежний run-list при форматировании был уничтожен, зеркальная копия также пострадала. Ничего другого не остается, как собирать все фрагменты руками. Звучит намного страшнее, чем выглядит. В отличие от всех остальных файлов диска $MFT-файл имеет замечательную сигнатуру FILE, присутствующую в начале каждой файловой записи. Все, что нам нужно, – последовательно сканируя раздел от первого кластера до последнего, выписать начало и конец каждого из фрагментов, принадлежащих MFT. Затем из этой цепочки необходимо исключить $MFTMirr. Его легко узнать – он расположен в середине раздела и содержит копии файловых записей $MFT, $MFTMirr, $LogFile и $Volume, причем $MFTMirr ссылается сам на себя. Допустим, наш список выглядит так: 08h – 333h, 669h – 966h, 1013 – 3210h. В грубом приближении ему будет соответствовать следующий run-list: 12 2B 03 08 22 23 03 69 96 22 FD 21 13 10 00. (Подробнее о кодировании/декодировании run-list см. «Списки отрезков» в прошлой статье этого цикла).

«В грубом» потому, что мы не знаем, в какой последовательности располагались эти отрезки в файле (порядок расположения фрагментов на диске далеко не всегда совпадает с порядком отрезков в run-list). Что произойдет, если порядок сборки $MFT-файла окажется нарушен? А вот что – внутри MFT все файловые записи ссылаются друг на друга по своему порядковому номеру, представляющему индекс массива. Эти ссылки необходимы для восстановления структуры директорий, организации hard link и еще кое-чего. Ссылки на материнский каталог дублируются в индексах и восстанавливаются элементарно. Hard link мрут безвозвратно (ну разве что попробовать пересобрать $MFT-файл в другом порядке), но они практически нигде и никем не используются, как говорится, было бы что терять. По-настоящему туго приходится сильно фрагментированным файлам, занимающим несколько файловых записей, раскиданных по разным $MFT-фрагментам. Здесь выручает только перестановка фрагментов. К счастью, количество комбинаций обычно бывает невелико и процедура восстановления занимает совсем немного времени. Хорошая новость – начиная с NTFS версии 3.1 (соответствующей Windows XP) в MFT номера файловых записей хранятся в явном виде (четырехбайтовое поле, расположенное по смещению 2Ch от начала FILE Record), что делает задачу восстановления тривиальной.

Восстановление после тяжелых разрушений

В результате сбоя содержимое дискового тома может стать недоступно операционной системе, и при попытке чтения его оглавления будут выдаваться сообщения в стиле «Файл или папка повреждены. Чтение невозможно», «Нет доступа к диску», «Системе не удается найти логическое устройство» и т. д. Chkdsk говорит, что «Повреждена основная таблица файлов» и прекращает работу. Караул! Верните мой том!

Не паникуйте! Попробуйте запустить NT Explorer и посмотрите, что он покажет. Маловероятно, чтобы содержимое всего тома было утеряно целиком (это же что такое с ним нужно было сделать?!). Если хотя бы часть файловых записей уцелела, R-Studio/GetDataBack/EasyRecovery их обязательно восстановят!

Анализ показывает, что основной причиной, по которой chkdsk отказывается проверять том, обычно становится порча файловой записи, описывающей $MFT. Если в процессе обновления $MFT внезапно отключить питание – такой исход событий вполне вероятен, особенно на жестких дисках с емким аппаратным кэшем – они не успевают завершить сохранение секторов на энергии, накопленной в конденсаторах, а вот их младшие собратья с этим справляются.

То же самое происходит при неудачном перемещении $MFT-файла или физическом разрушении первого MFT-сектора. Зеркальная копия $MFT во всех этих случаях остается цела, однако chkdsk по каким-то таинственным причинам не хочет ей пользоваться, и вы должны восстановить ее самостоятельно. Просто скопируйте первый сектор $MFTMirr в первый сектор $MFT.

Поклонники Sector Inspector могут воспользоваться командным файлом следующего содержания.

Листинг 1. Командный файл для ручного восстановления $MFT из $MFTMirr, XXX – номер сектора $MFTMirr, YYY – номер сектора $MFT

SECINSPECT.EXE -backup d: backup.dsk XXX 1

SECINSPECT.EXE –restore d: backup.dsk YYY CONFIRM

Теперь можно смело пускать chkdsk. Если же он по-прежнему не работает, значит, либо поврежден загрузочный сектор (а методику его восстановления мы уже обсуждали), либо run-list файла $MFT:$DATA не совпадает с истинным началом MFT (найдите сектор с файловой записью $MFT внутри и исправьте run-list), либо размер кластера, прописанный в boot-секторе отличается от его фактического размера (о том, как определять истинный размер кластера, мы уже говорили выше).

Если же сбой был настолько серьезен, что вместе с $MFT пострадало и зеркало, задача сводится к восстановлению отформатированного диска. Кстати говоря, при тяжелых разрушениях файловой структуры, когда на диске образуется настоящий кавардак, восстановление тома полезно начинать с… его форматирования. Нет, это не первоапрельская шутка! Утилита format формирует заведомо исправные ключевые структуры, ну а подключение файловых записей – не проблема. Главное – сохраните run-list файла $MFT:$DATA, если, конечно, он еще уцелел. Все остальное – дело техники!

Рисунок 7 . Безуспешная попытка прочитать поврежденный том

Наш затянувшийся разговор о восстановлении данных подходит к своему логическому концу, однако NTFS не стоит на месте, а интенсивно развивается. И хотя до сих пор эти изменения носили чисто косметический характер, в Windows Longhorn все обещает кардинальным образом измениться. Microsoft активно работает над новой файловой системой – Windows File System, или сокращенно WinFS, сроки выхода которой, кстати говоря, постоянно переносятся (разработка файловой системы это не шутка!).

По словам вице-президента Microsoft Боба Маглиа, WinFS – это все та же NTFS, с прикрученным SQL и XML. Насколько изменятся базовые структуры файловой системы общественности до сих пор неясно. И уж совсем непонятно, зачем NTFS понадобился реляционный SQL, когда эти возможности в нее закладывались изначально, просто их не успели доделать. Любой системный программист запросто напишет драйвер, принимающий SQL/XML запросы и транслирующий их в обращения к драйверу текущей файловой системы! Что-либо менять внутри NTFS совсем необязательно. Сдается мне, что это всего лишь очередной маркетинговый трюк, подталкивающий пользователей к переходу на Longhorn!

С другой стороны, развитие NTFS можно только приветствовать, поскольку оно дает пищу всем специалистам по восстановлению данных, ведь старые утилиты с новой файловой системой скорей всего окажутся несовместимы.

Восстановление NTFS-тома, отформатированного под FAT16/32

При переформатировании диска операционные системы семейства NT никогда не изменяют тип файловой системы (разве что попросить их это сделать явно), поэтому непреднамеренное форматирование NTFS-раздела в FAT16/32 крайне маловероятно. Windows 9x/MS-DOS, напротив, любой диск стремятся отформатировать под FAT16/32, не замечая, что на нем что-то уже находится. Непреднамеренная порча NTFS-разделов при установке Windows 9x/MS-DOS поверх Windows NT – обычное дело, через которое проходит уже второе поколение пользователей.

Стратегия спасения данных во всем похожа на восстановление NTFS-тома, отформатированного под NTFS, с той лишь разницей, что при создании таблицы размещения файлов (file allocation table) первые несколько тысяч файловых записей в MFT затираются безвозвратно (впрочем, их еще можно собрать руками, действуя по методике описанной в разделе «Разгребая кластерные обломки» предыдущей статьи этого цикла).

Файлы с уцелевшей FILE RECORD легко восстанавливаются R-Studio/GetDataBack/EasyRecovery. Для ручного восстановления всего тома его необходимо заново отформатировать под NTFS, предварительно определив количество секторов в кластере. Далее действуем по плану – увеличиваем размер $MFT, пускаем chkdsk и собираем все, что только можно собрать. Поскольку количество файлов, хранящихся на современных дисках, зачастую исчисляется многими миллионами, потеря первой тысячи из них не так уж и страшна (если только по закону подлости это не будут самые ценные файлы).

Почему погибают дисковые разделы? Ниже приводится список наиболее распространенных причин, отсортированных в порядке убывания их «популярности»:

ошибки оператора, вирусы, троянские программы;
отключение питания/зависание системы во время интенсивных дисковых операций, сопровождаемых обновлением MFT (например, удаление/добавление файлов или каталогов);
некорректное поведение различных дисковых утилит (Partition Magic, Ahead Nero, Norton Disk Doctor и т. д.);
физические дефекты оперативной памяти, приводящие к нарушению целостности дискового кэша и как следствие – порче самого диска;
некорректное поведение привилегированных драйверов, случайно или преднамеренно «залетающих» внутрь служебных структур NTFS-драйвера .

Полезные советы – план превентивных действий по спасению данных

Чтобы предотвратить разрушение тома и упростить задачу восстановления данных, рекомендуется заблаговременно выполнить следующий комплекс мероприятий:

Переместите $MFT подальше от начала раздела. Первые секторы раздела, как показывает практика, самое небезопасное место. Во-первых, сюда стремятся вирусы (миф о невозможности прямого доступа к диску под NT всего лишь миф – читайте описание функции CreateFile и инструкцию на ASPI32-драйвер), во-вторых, некоторые утилиты (и в частности Ahead Nero) при некоторых обстоятельствах путают жесткий диск с оптическим накопителем, записывая образ не «туда», а, значит, в первых ~700 Мбайтах физического диска (не логического тома!) не должно быть ничего ценного, в-третьих, если вы вдруг запустите WipeDisk или любую другую затирающую утилиту, первым погибнет именно $MFT, без которого весь дисковый том просто груда мусора, в-четвертых… да много разных причин можно найти. Просто переместите $MFT, вам что – трудно? Достаточно взять любой дефрагментатор, распространяющийся в исходных текстах (энтузиасты! ау! присоединяйтесь к проекту http://sourceforge.net/projects/opendefrag), и слегка доработать его «напильником» под наши нужды. Естественно, валерьянка и резервная копия обязательно должны быть под рукой!
Не допускайте фрагментации $MFT-файла! Не создавайте на диске огромного количества мелких файлов и не заполняйте его более чем на 90%. Стандартный дефрагментатор, входящий в комплект штатной поставки Windows 2000/XP, не позволяет дефрагментировать $MFT, и приходится прибегать к сторонним средствам, лучшим из которых на мой взгляд является O&O Defrag Pro от одноименной компании (http://www.oo-software.com/). Это действительно профессиональный дефрагментатор, к тому же поддерживающий командную строку.
Периодически создавайте резервную копию файловой записи $MFT – для этого достаточно сохранить один-единственный (!) сектор – первый сектор MFT, номер которого содержится в boot, только не забывайте его периодически обновлять, ведь при добавлении новых файлов/каталогов MFT планомерно расширяется и старые списки отрезков становятся все менее и менее актуальны.

Рисунок 8. Нормальный дисковый том (MFT, выделенный желтым цветом, расположен в начале раздела)

Рисунок 9. «Иммунизированный» дисковый том (MFT расположен в середине)

Как исправить ошибку NTFS Partition Is In An Unsafe State в Linux

Подписаться на Google News

На днях я загрузил систему Windows 10 с Ubuntu live cd. Когда я попытался смонтировать раздел Windows из среды Linux live cd, раздел windows отказался монтироваться в режиме чтения/записи и отобразил эту ошибку – NTFS partition is in an unsafe state (раздел NTFS находится в небезопасном состоянии).

sudo mount /dev/sda2 /mnt/

Здесь /dev/sda2 – это раздел Windows.

Windows is hibernated, refused to mount. The disk contains an unclean file system (0, 0). Metadata kept in Windows cache, refused to mount. Falling back to read-only mount because the NTFS partition is in an unsafe state. Please resume and shutdown Windows fully (no hibernation or fast restarting.) Could not mount read-write, trying read-only

Ошибка – раздел NTFS находится в небезопасном состоянии. Раздел монтируется в режиме только для чтения, но не для записи. Я подумал, что это произошло из-за неаккуратного выключения, поэтому я правильно выключил систему Windows и снова загрузил ее с live cd. Однако я получаю то же сообщение об ошибке. Я вошел в систему Windows, а затем перезагрузил ее. Но я все равно получал ту же проблему снова и снова. Я выполнил команду ntfsfix , которая используется для исправления ошибок в разделе NTFS :

sudo ntfsfix /dev/sda2

Mounting volume. Windows is hibernated, refused to mount. FAILED Attempting to correct errors. Processing $MFT and $MFTMirr. Reading $MFT. OK Reading $MFTMirr. OK Comparing $MFTMirr to $MFT. OK Processing of $MFT and $MFTMirr completed successfully. Setting required flags on partition. OK Going to empty the journal ($LogFile). OK Windows is hibernated, refused to mount. Remount failed: Operation not permitted

К сожалению, это не сработало. Я не смог смонтировать раздел Windows в режиме чтения/записи с Linux live cd.

В конце концов, я решил проблему ошибки «NTFS partition is in an unsafe state», отключив функцию «Быстрый запуск « в моей системе Windows 10.

Для тех, кто не может смонтировать раздел Windows с Linux live cd с двойной загрузкой Linux и Windows, просто отключите функцию быстрого запуска в Windows 10 или 8, чтобы смонтировать раздел Windows NTFS в режиме чтения/записи, как показано в следующих шагах.

Отключение быстрого запуска в Windows

Чтобы отключить быстрый запуск в Windows 10, откройте Панель управления -> Оборудование и звук.

Нажмите Оборудование и звук Далее нажмите «Параметры питания «.

Нажмите Параметры питания В следующем окне нажмите «Выберите, что делает кнопка питания « на левой боковой панели.

Выберите опцию «Что делает кнопка питания «В разделе «Определить кнопки питания и включить защиту паролем» вы увидите ссылку «Изменить настройки, которые сейчас недоступны «. Нажмите на нее.

Изменить параметры, которые в данный момент недоступны. Уберите флажок «Включить быстрый запуск», чтобы отключить быстрый запуск, и нажмите Сохранить настройки.

Уберите флажок «Включить быстрый запуск» Теперь быстрый запуск отключен. Закройте приложение Control Panel. Теперь я могу монтировать раздел Windows в режиме чтения-записи без каких-либо проблем. Надеюсь, это поможет.

Зарубин Иван Эксперт по Linux и Windows

Парашютист со стажем. Много читаю и слушаю подкасты. Люблю посиделки у костра, песни под гитару и приближающиеся дедлайны. Люблю путешествовать.

Форум русскоязычного сообщества Ubuntu

Увидели сообщение с непонятной ссылкой, спам, непристойность или оскорбление?
Воспользуйтесь ссылкой «Сообщить модератору» рядом с сообщением!

Форум русскоязычного сообщества Ubuntu »
Поддержка »
Настройка системы (Модераторы: Дмитрий Бо, www777) »
Автомонтирование Windows раздела с правами на запись

Страницы: [1] Вниз

Автор Тема: Автомонтирование Windows раздела с правами на запись (Прочитано 1902 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Страницы: [1] Вверх

Форум русскоязычного сообщества Ubuntu »
Поддержка »
Настройка системы (Модераторы: Дмитрий Бо, www777) »
Автомонтирование Windows раздела с правами на запись

Страница сгенерирована за 0.035 секунд. Запросов: 25.

Сайт
Об Ubuntu
Скачать Ubuntu
Семейство Ubuntu
Новости

Форум
Помощь
Правила

Документация
Пользовательская документация
Официальная документация
Семейство Ubuntu
Материалы для загрузки
Совместимость с оборудованием
RSS лента

Сообщество
Наши проекты
Местные сообщества
Перевод Ubuntu
Тестирование
RSS лента

Logfile ntfs как отключить