Всякий раз, когда я отключаю USB-накопитель с помощью Nautilus и подключаю его к машине с Windows, я получаю предупреждение о необходимости ремонта накопителя.
(то же сообщение, что и на этом скриншоте)
За 10 с лишним лет работы с окнами у меня никогда не было поврежденного или поврежденного USB-накопителя, но в течение последних двух лет три моих USB-накопителя перестали работать, поэтому я не могу этого доказать, но очевидно, что это связано с поведением Ubuntu (не) монтирования ,
Мой друг сказал мне, что я могу предотвратить такой ущерб, используя udisks и синхронизацию, но я надеюсь, что это не способ сделать это, подключая диски с помощью команд оболочки в 2016 году.
windows
filesystem
ntfs
fat32
jan6352781
источник
источник
sync
в оболочке перед размонтированием в Ubuntu? (маловероятно) 2) Попробуйте записать только один файл за раз, размонтируйте, а затем проверьте, можно ли читать этот файл в Windows, и его содержимое обновлено, несмотря на появление этого предупреждения. 2) означает, что проблема, скорее всего, связана с тем, что Windows суетливо говорит «мы нашли ошибки» по поводу некоторой не реальной проблемы.Stage 2: Examining file name linkage ... Found corrupt basic file structure for "<0x32,0x1e63>" ... queued for offline repair. Found an unneeded link ($FILE_NAME: ???) in index "$I30" of directory "\ <0x5,0x5>" ... queued for offline repair. Found missing Index entry for file "<0x32,0x1e63>" from index "\??\D:\found.000" of directory "$I30" ... queued for offline repair.
¯\(o_o)/¯
Ответы:
Не беспокойтесь, Ubuntu не повредил ваш USB-накопитель. Но мы не используем плохо документированные битовые флаги файловой системы FAT32, FAT16 или NTFS. В Windows эти флаги указывают на возможно поврежденную файловую систему, когда мы неправильно отключили диск или произошла ошибка ввода-вывода.
Эти биты находятся в зарезервированной записи таблицы разделов FAT. Согласно внутренней статье Microsoft за 2004 год, целью этих битов являются:
Несколько лет назад с разработчиками файловой системы ядра было некоторое обсуждение того, как преодолеть это, но я не смог проследить результаты. По-видимому, он не попал в последние ядра.
Поскольку используется только битовый флаг, но в целом наши данные должны быть в идеальной форме, мы можем игнорировать предупреждающие проблемы Windows на тех дисках, которые мы ранее использовали в Ubuntu.
источник
Это в основном проблема с Windows. Он думает, что это единственная ОС в мире и действует, если обнаруживает что-то, чего не понимает.
Только потому, что Windows говорит, что вы должны восстановить диск, это не значит, что это правда.
Любой из моих дисков, используемых с Ubuntu, получает это сообщение от Windows, я просто говорю,
no
и они прекрасно работают с Windows.Короче говоря, с диском все в порядке, просто есть что-то, чего не понимает Windows, и ее ответ - уничтожить его.
Не
repair
используйте диск, он отформатирует его, не сказав вам, и вы потеряете все данные на диске.источник
Как вы предложили в комментарии, это, возможно, связано с тем, что Ubuntu не завершает процесс записи перед удалением флэш-накопителя. Ubuntu записывает файлы в ОЗУ во время процесса копирования и записывает эти файлы из буфера на USB-накопитель в фоновом режиме после закрытия диалогового окна копирования. Есть другой ответэто говорит о том, что это особенно проблема для машин с большим объемом памяти, но вполне вероятно, что вы извлекаете диск до завершения фоновой записи. Когда вы извлекаете диск, это заставляет буфер записываться на диск, но трудно сказать, когда запись фактически завершена. Существует всплывающее окно в более новых версиях (наверняка 15.10, возможно, 15.04), предназначенное для исправления этого - через некоторое (обычно короткое) время появляется пурпурное предупреждение, в котором говорится, что однажды что-то вроде «[Диск] теперь можно удалить» один раз запись закончена
Это, вероятно, причина, по которой ваш друг предложил синхронизировать. Запуск
sync
в терминале заставляет все буферизованные данные записываться на диск и должен возвращаться только после завершения записи (см. Этот ответ ). Посмотрите этот ответ для утилиты, которая поможет вам определить, действительно ли это проблема.источник
eject
в терминале, и есть заметная задержка, прежде чем он вернется, если я только что скопировал большой файл.Я видел множество USB-накопителей, особенно флэш-карт (SD и т. Д.) В USB-адаптерах, в которых файловые системы FAT (практически каждый USB-диск предварительно отформатирован с FAT32) были повреждены при использовании дистрибутивов Ubuntu и Ubuntu. Это было почти регулярное явление каждые несколько месяцев регулярного ежедневного использования.
Если бы это была аппаратная проблема, то форматирование разделов с помощью ext3 (или 4) не помогло бы, но ext3 / 4 делает файловые системы практически пуленепробиваемыми. (ext2 также был поврежден в течение нескольких месяцев, которые я пробовал; предполагалось, что было меньше записей, поэтому более длительный срок службы флешек, в основном из журнала).
Итак, Ubuntu не должен физически повреждать сами USB-накопители, но я все еще не доверяю ему на 100% с файловыми системами FAT.
Я думаю, что лучше всего избежать повреждения файловой системы:
umount
/ извлечен. Даже если в данный момент диск ничего не записывает (если он горит, он не мигает), и даже если вы сделали это,sync
файловая система все еще можетumount
/ извлечения, прежде чем отключать его. Кажется, что даже послеumount
активности диска иногда может мигать некоторое время. Другие пользователи, как этот парень, говорят, что это может продолжаться до минуты.sync
одного, как этот парень, который получил повреждение файла.Связанные (как правило) ссылки:
источник
Это имеет мало общего с любой операционной системой. Это ошибка файловой системы, которая в большинстве случаев указывает на то, что диск не был размонтирован должным образом (ошибка пользователя). Это не абсолютный признак ущерба, он просто указывает на возможность повреждения. Если присутствует, повреждение обычно ограничивается последним записанным файлом (ами). В этом случае команда Windows «Восстановить» сканирует диск на наличие секторов, помеченных как «занятые», но не назначенные какому-либо файлу, а затем назначает эти фрагменты и фрагменты новым файлам.
Эта ошибка также может быть создана в Windows, если вы просто извлекаете диск во время записи, не отключая его сначала (в Windows «Eject» выполняет размонтирование).
Это сообщение означает, что диск не был размонтирован должным образом.
Вы можете самостоятельно проверить, действительно ли файловая система была повреждена или это просто ложное срабатывание: если после запуска «Восстановить» появляется новая папка с именем «found000» с некоторыми файлами в ней, это означает, что действительно была незаконченная запись, которая был прерван. Некоторые из ваших данных были потеряны, и это вызывает беспокойство.
источник
Я использую несколько лет Ubuntu и Windows с двойной загрузкой, и когда я размонтирую диск правильным способом, в Windows всегда появляется сообщение об ошибке, но никогда не было ошибки на моем USB-диске. В W10 вы можете отключить это всплывающее сообщение об ошибке.
источник
Практически невозможно, чтобы любая ОС могла повредить USB-накопитель, после нормального формата (не быстрого) не должно быть никаких следов того, что диск когда-либо использовался с Ubuntu.
Проверьте диски с помощью «H2testw» или «USB Flash Drive Tester» - плохие сектора могут быть источником многих странных ошибок.
источник
Я не могу сказать, был ли диск "поврежден", возможно это было и возможно это не было. Но как человек, который может сказать то же самое: «Более 10 лет работаю с Windows ...», я могу вам сказать, что если вы работаете с Windows 10, это может стать источником ваших новых проблем. В первый день 10 декабря я столкнулся с новой проблемой: в 10 создается база данных для внешних накопителей (это может быть база данных индексации, я не помню). Если эта база данных не соответствует диску, она сообщит вам, что ваш диск поврежден, иногда вы можете игнорировать это предупреждение, а иногда нет (см. Анекдот). Запуск «ремонт» будет исправить базу данных.
Анекдот:
Бег
sync
тоже не плохая идея.источник