Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток Научпоп доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 163
Битые файлы это еще полбеды. Прибегают юзеры с круглыми глазами, когда файловая система RAW и винда предлагает флешку отформатировать. "А у меня же там вся работа, вааа!". После чего файлы можно вытащить только специальными программами, и то без 100% гарантии. А все потому что человеку лень значок в трее нажать.
И даже после восстановления они в 9 случаях из 10 продолжают делать ровно то же самое)
Я один раз в жизни столкнулся с RAW вместо 500 Гб HDD, и очень огорчившись стал искать способы не "вытащить файлы", а восстановить всё как было. Не мог поверить, что структура просрана и невосстановима.
Из всех перепробованных утилит всё обратно в прежнем виде вернула китайская DiskGenius, причём буквально за секунды, дольше разбирался как это сделать.
Прошло лет много, может кто-то ещё научился это делать, но тогда, давно, — вот так. Просто поделился опытом.
если он сделал это за секунды, то полагаю, что это было быстрое сканирование потерянных разделов, а делает он это путем поиска и перечитывания резервной GPT таблицы в конце диска, иначе сканировать ему придется весь диск, что долго и медленно
gdisk - вспомнил, им я флешки восстанавливал аналогично
DMDE так же умеет делать. И тоже - дольше разбираешься "как".
И мне помогла DMDE в такой ситуации. Теперь всегда держу её рядом.
всё потому, что людям в школе не объяснили, что нельзя на съёмных носителях держать важную информацию в единственном экземпляре
Когда я работал в "скорой компьютерной помощи", видел такое постоянно. Некоторые люди были готовы платить большие деньги, чтобы хоть что-то из таких флешек потом вытащить (делайте бэкапы, господа!).
Не следует лезть в такие дебри и исследования - безопасно ли на самом деле вытаскивать флешку без отключения или нет. Есть известная, установленная правильная процедура, согласно которой надо нажать на иконку в трее. Её и надо придерживаться в любых обстоятельствах.
Понимаете - то, что вы будете лезть в дебри, гадать что-то там, выяснять - тут можно и облажаться. Что-нибудь не учесть, какой-нибудь неизвестный фактор сыграет. Оно не надо такое. Если вы соблюдаете процедуру - вы получаете гарантированный результат. Вот бы ещё разработчики винды позволили не делать лишних кликов - а сразу сделали кнопку на видном месте, отключающую флешку. Или иконку на рабочем столе/меню пуск. Причём сделали всё это настраиваемой возможностью, а не изначально существующей фичей. Очень жаль, что в Windows 11 нету Quick Launch bar на панели задач.
Настраиваемая фича: вытаскиваешь на рабочий стол диск, который USB drive. При необходимости безопасно извлечь, нажимаешь на нем правой кнопкой мыши и выбираешь eject.
вытаскиваешь на рабочий стол диск
Как-то Сисадмин спросил:
— Учитель, не желаете ли красивую картинку для вашего десктопа? У меня есть хорошая коллекция обоев для рабочего стола со звездным небом и моральным законом.
— Почему ты думаешь, что мой нынешний wallpaper хуже? — спросил в ответ Инь Фу Во.
— Я не знаю, какая у вас картинка сейчас. Я никогда не видел вашего десктопа. У вас всегда открыто множество окон.
— Я тоже его никогда не видел, — сказал Инь. — Я работаю.
Проблема с "безопасным извлечением" в том, что это достаточно долго и требует телодвижений: отвлечься, подвести мышу куда надо, нажать (а теперь еще нажать ДРУГУЮ кнопку и ВЫБРАТЬ)
Сравните с действием "выдернуть".
Тогда уж лучше настроить хоткей, чтобы при нажатии на него сначала само вылезло ругательное окошко, и вот только если в нем нажата правильная кнопка - оно отмонтировалось бы и написало "готово". Это быстрее - и то всё будут забиывать
Или иконку на рабочем столе/меню пуск.
Или ставите SysInternals и там есть sync.exe.
sync.exe -e E:Или можно обойтись powershell (но не тестил)
$v = Get-CimInstance Win32_Volume -Filter "DriveLetter='E:'"
Invoke-CimMethod -InputObject $v -MethodName Dismount -Arguments @{ Force = $true; Permanent = $false }
Закрепить в панель задач или "Пуск" ярлык на rundll32.exe shell32.dll,Control_RunDLL hotplug.dll , как вариант; либо использовать утилиты, заменяющие панель задач, которые вернут в Windows 11 утраченную функциональность.
Не следует лезть в такие дебри и исследования
-> Автору и пользователю знать не положено.
Есть известная, установленная правильная процедура
Постулат.
Её и надо придерживаться в любых обстоятельствах.
Видите ли, как раз из-за того, что жизнь переполнена недообъяснёнными процедурами, оказывается вообще не понятно, что нужно или нет. Может что-то потеряло актуальность. "Так делали всегда, не выделывайся."
И когда ОС по-бюрократически обще объясняет "may lead to data loss", то не хватает буквально параграфа по F1, объяснить, что процесс записи не заканчивается полосой прогресса. И если система или контроллер не успеют записать и устаканить данные, то потеряться может не только последний файл, а вообще вся файловая система навернуться.
Или в следующем обновлении разработчики Windows / Linux / FreeBSD / GNOME / macOS что-то поменяют, и привет.
У винды в свойствах флешки можно отключить кеширование и оставить немедленную запись. Если любите выдёргивать флешки, то включите и не парьтесь.
Не без глюков.
Что Форточки, что пингвин, именно флешку воспринимают как чужеродное нечто.
Для любителей выдёргивать лучше обзавестись качественным ССД в формфакторе флешки.
Вы же прочитали раздел под названием "Откуда вообще взялась кнопка"?
Не поможет.
Безопасное отключение еще по идее может питание порта отключать, куда уж безопаснее и полезнее для электроники
За эти годы ни разу не видел чтобы после безопасного отключения порт обесточивался. Даже на брендовых материнках.
есть
светодиодики очень часто есть на съемных hdd/ssd, гаснут после команды изымания
Это же не светодиод питания
светится когда запитан, моргает при чтении/записи
Когда запитан или когда драйвера с контроллером договорились? Если воткнуть в блок питания - огонек загорится? А то, что моргает во время работы - как раз намек, что это не просто наличие питания.
питание не снимается. светодиод тушит прошивка, потому что с девайсом нет соединения. не выдумывайте то чего нет
тут посыл в том, что диод может стоять уже во внутренней логике устройства.
А учитывая, что он обычно моргает при чтении\записи, наверняка он и стоит где-то за контроллером, на одной из ножек. Так вот если контроллеру пришла команда "спать", и диод потух, это ведь не значит, что сама шина USB обесточена, на ней по-прежнему есть ток
УПД: не дочитал тред до конца, выше уже отписали(
Зачем-то вспомнил, что в бытность ХР при безопасном извлечении флешки светодиод на оной гас, а как поставил 7 в 2009 — ни разу более такого не видел, тыкай безопасное извлечение не тыкай, светодиод гореть будет. Вроде даже НЖМД внешние не останавливались и после «безопасного» извлечения визжали аварийной парковкой.
В линуксах строго замечал, что флешка гаснет.
Есть такое. Они теперь тоже останавливаются, но, видимо, уже сами, по своей внутренней логике - где-то через пол-минуты - минуту после безопасного извлечения.
MS поменяли дефолтное поведение. XP физически снимала питание с порта при безопасном поведении (и на дешёвых материнках это могло снять питание со всего хаба), а начиная с висты они стали использовать энергосберегайку ACPI D3, с которой даже сейчас у некоторых девайсов есть проблема - они не могут из неё проснуться после гибернации/сна. Все сторонние драйверы чипсета тех времён добавляли в реестр параметр DisableOnSoftRemove = 1, чтобы вернуть поведение как в XP :)
Кстати да, у меня есть старая флэшка Diesel с индикатором, который показывает и обмен и питание, можно понять, когда ее можно выдернуть. У современных увы такого нет, наверное на светодиодах экономят (ага, полцента).
Если не меньше
Тоже ориентируюсь на индикатор на флешке или возле разъема. Погаснет и плюс ещё секунда и можно вынимать
Индикатор обмена встречаю сейчас везде, даже на самых дешевых китайских флешках. Даже на подделках (это которые прикидываются 32 гб а по факту там 2 гб). Не знаю, кто уж там на чем экономит.
Кстати на брендированных флешках такой светодиод можно и не увидеть - или корпус непрозрачный и окошко не вывели, то ли берут самый древний дешман без индикатора.
А вот с MicroSD ситуация как в посте. Да и нечасто мы эту мелочевку туда-сюда вставляем, в отличие от обычных.
Один раз я себе так материнку спалил, неудачно выдернув флэшку. Бес его знает, отключается ли там порт или нет, но как-то спокойнее.
В новых дорогих материнках, обычно, стоит нормальная защита по току на USB. У нас был случай, когда на метеринках горели USB 2.0, при этом 3.0 оставались целые. По видимому, там была разная разводка по питанию.
2.0 и 3.0 независимы на логическом уровне. Можно соорудить пассивный переходник разветвитель, все будет работать.
У вас выгорела логика 2.0
На многих ноутах защитой обычно и не пахнет, а т.к. usb идёт напрямую в процессор, это одна из популярных причин их смерти(по отзывам сервисов).
Вот пример. Парень вставил куда не надо. По ноутбуку как Мамай прошёл. Повыгорала куча вспомогательных чипов. и Процессор.
В теории, если замкнуть питание на шину, можно убить и процессор.
Я взял первую попавшуюся схему и тут стоит usb напрямую в Z370
Скрытый текст
Если это usb 2, то один ампер ещё не так страшно
Скрытый текст
А если usb 3, то там аж 5.6 ампера
Скрытый текст
Безопасное отключение еще по идее может питание порта отключать
В теории может (и вроде даже кое-где делает для экономии энергии), но при размонтировании не отключает (по крайней мере сразу). В реальности оно вроде посылает команду на выключение устройству, и устройство "у нутре" само выключает свое питание. Но не все устройства так умеют (в том числе контроллеры внешних жестких дисков, не говоря уже о флэшках).
А я руками от рута делаю echo 1 > /sys/block/sdd/device/delete
Это было бы странно, так как новому устройству, подключённому к этому же порту, питание с этого порта получить было бы невозможно.
а как тогда узнать, что к порту подключен новый девайс?
в режиме питания не могу вспомнить ни одного usb-устройства, которому бы это вредило. Ну может жесткий диск будет вечно крутиться, подключенный через переходник. Но это надо его месяцами в порту держать, чтобы возможно это как-то на него повлияло.
в линуксе еще можно принудительно скинуть на диск страничный кэш командой sync - как отработало, так и скинулось.
"а на Linux перед этим набираю sync и терпеливо жду, пока он вернет управление" - это цитата из заметки
В Cinnamon флэшка извлекается одним кликом, после чего системная всплывающая подсказка говорит о том, можно или нельзя её сейчас выдёргивать. Если нельзя, то потом скажет, когда можно будет, если я ничего не путаю. sync удобнее, только если я флэшкой в консоли работать изначально, имхо.
Пользоаателям нужно сказать, чтобы открыли консоль, набрали sync, подождали завершения и так каждый раз. Пользователи итак злые. Нужно упырей отечественных, собирающих большие деньги напрягать.
Флэшки -- это чужеродное Маку устройство. )))
Во времена, когда основным носителем была дискетка -- проблема решалась радикальнее. На флоповодах у Мака просто не было кнопки извлечения! Вытолкнуть его из дисковода могла только сама MacOS. Естественно, пока все операции записи на носителе не закончены -- она его не вытолкнет. )))
Да, это было гениальное решение. Ни одна тупая секретарша не могла запороть файлы на дискете. Один только крсяк был: для выталкивания дискеты нало было ее иконку перетащить в мусорную корзинку... Что в 1984 году курили эппловские дизайнеры???
Хм, у них на мышке была только одна кнопка, так что вариантов не много. 😉 Но этот интерфейс используется и поныне. Забавно, что когда в Корзину суёшь один том, он тут же предлагает и остальные тома с этого устройства, что б дважды в Корзину не выкидывать. 😉
Правда, сейчас иконка Корзины меняется, что б не так страшно было.
Мышка с одной кнопкой — это как раз логично: идеология point and shoot...
Drag-and-drop (Drag-and-trash или Drag-and-eject) это ж тоже весьма и весьма логично. 😉
Но, да, логика у всех своя. Лично я, вероятно, как параноик, предпочитаю правую кнопку более-менее современных мышек или двухпальцевый жест на тачпаде для выпадающего меню.
Но не в помойку же. Кажется первая ассоциация стереть, а не достать из корпуса.
Вот именно. Некоторые вообще могут подумать, что диск физически уничтожится, тем более, что он внутри корпуса полностью...
В 1984 году картинка была другая...
Надо думать, дизайнеры 42 года не сидели без дел. 😉 За System 1 ничего сказать не могу. У меня было шапочное знакомство c System 8, а может и с Mac OS 9, но тоже не помню.
Но в Mac OS X 10 иконка Корзина/Trash при перетаскивании устройства менялась на символ извлечения, правда, название оставалось неизменным (впрочем, у современных так же).
Мышка с одной кнопкой —
Самое веселое начинается, когда безопасное извлечение блокирует какой-нибудь процесс, а Process Explorer показывает на системный Проводник 💀
SysinternalsSuite Руссиновича ещё можно попробовать задействовать более полно, понимая риски?..
usage: handle [[-a [-l]] [-v|-vt] [-u] | [-c <handle> [-y]] | [-s]] [-p <process>|<pid>] [name] [-nobanner]
-a Dump all handle information.
-l Just show pagefile-backed section handles.
-c Closes the specified handle (interpreted as a hexadecimal number).
You must specify the process by its PID. Requires administrator
rights.
WARNING: Closing handles can cause application or system instability.
-g Print granted access.
-y Don't prompt for close handle confirmation.
-s Print count of each type of handle open.
-u Show the owning user name when searching for handles.
-v CSV output with comma delimiter.
-vt CSV output with tab delimiter.
-p Dump handles belonging to process (partial name accepted).
name Search for handles to objects with <name> (fragment accepted).
-nobanner Do not display the startup banner and copyright message.
Грохнуть проводник, делов то. Потом запустить explorer
В линуксе можно монтировать флэшку в режиме, когда запись в принципе не кэшируется (-o sync). Тогда ее можно выдергивать сразу после завершения записи с очень малой вероятностью проблем.
sync option only has an effect on ext2, ext3, ext4, fat, vfat, ufs, and xfs filesystems
На ntfs не сработает, судя по всему.
Хм, а Вы пробовали так монтировать? С параметром sync скорость работы флэшки падает несколько раз и, вероятно, износ растёт в несколько раз, но износа не видно.
В статье упоминается -o flush, который для этого предназначен. Хотя автор отзывается о нём, как о малополезном параметре. Не знаю, формально выглядит боле-менее рабочим. Но реакция на прерывание программы так себе - длительное ожидание, что, как бы, свидетельствует, что таки в кэш таки накапливаются множество изменённых блоков, просто из сбрасывают на закрытии файла (или до завершения программы).
Плюс, vfat его поддерживает, но exfat - нет.
>запись в принципе не кэшируется
>С параметром sync скорость работы флэшки падает несколько раз
Даже интересно, с чем это может быть связано
например с тем, что "кластер" на флешке это 1МБ, а на ФС - типично 4КБ
вот и приходится писать мегабайт на каждую единичную запись
Как бы, да, интересный факт, но чтение исходных кодов и SystemTap профилирование имеют смысл, только если есть желание сиё исправить. Но практический смысл исправления не ясен, т.к. даже после идеальных исправлений, при условии соблюдения семантики sync, лично я, в этом режиме работать не буду.
Замедление работы exfat с параметром sync в два-три раза понятно и его можно легко объяснить, но многократное замедление vfat с параметром sync так и осталось феноменом невыясненной природы.
Возможно, он не только слишком много пишет на флешку, но и слишком много читает с флешки? Кто знает?
Пока использовал один ПК с флешками было все в порядке, хотя некоторые флешки не отдавались даже спустя значительное время после окончания записи. Но вот пришлось носить данные между тремя ПК. За два месяца негодными стали несколько флешек, некоторые из старья, но некоторые по 32-128Гб. Потеря ощутимая, данные жалко. Восстанавливать удавалось не все флешки, но не данные - терялись. Решил отказаться от флешек и соединить ПК в единую частную сеть. Работает! Флешки лежат без употребления.
Спасибо, интересная статья для понимания что происходит. Сам стараюсь всегда использовать "безопасное извлечение".
На фото ниже приделал к usb удлинителю тумблер с подсветкой, разрывающий провод питания +5v. Это для ридера CF карты с фотоаппарата. Работает больше десятка лет. Вставляем карту, потом включаем питание, и скидываем файлы на комп. Далее жмем "извлечь", отключаем питание, и извлекаем карту из ридера.
Глядя на фото, я понял как сделать "диод для данных".
На али видел готовые юсб-кабеля с выключателем, только выключатель был не такой брутальный, а обычный как на светильниках ставят.
Я пользуюсь таким кабелем для приемника джойстика. С подключенным джойстиком Windows иногда гасит монитор, а иногда нет. Причем выявить закономерность мне не удалось, powercfg /requests ничего не показывает, а десятилетней давности вопросы таких же страдальцев на форумах получают только стандартные ответы "обновите драйвера и проверьте системные файлы".
На любой барахолке есть хабы с выключателями у каждого порта.
При этом стандарт usb предполагает ровно обратный порядок - первыми контакты замыкают шины питания и общий провод, последними D+ и D-
Я в курсе существования хабов с выключателями и не сталкивался с повреждением линий данных порта из-за подключения их до подачи питания, но хот плаг реализован физически более длинными контактами в разъёме.
потому что так учили еще в школьном компьютерном классе
Меня в школьном компьютерном классе учили дожидаться погасшей лампочки дисковода, прежде чем доставать из него 8-дюймовую дискету...
В условиях массовой несовместимости позиционирования головок дисководов ПЭВМ ДВК, меня дико бесила привычка ОС rt11 при каждой загрузке писать на дискету что-нибудь ((
Всё бы отдал за ридонли режим
Как бы, SET DX0 NOWRITE было, правда и SWAP.SYS был иногда необходим. Давно это было, не помню как решалось.
Всё бы отдал за ридонли режим
Чего ж кусочек изоленты не отдали?
Хм, ЕМНИП, на данной картинке, ровно наоборот, запись разрешена (как бы, сами подумайте, что даже синяя изолента хреново держалась на тех фторопластовых покрытиях, поэтому если она случайно отваливалась - запись блокировалась 😉).
Другое дело, что RT-11 (РАФОС), вроде как, имел ограничения при загрузке с носителей с защитой записи, т.к. ОЗУ 56 КиБ или даже 32 КиБ, это ж Вам не сейчас. Тогда были свои тонкости, которые уже и не упомнишь. 😉
У меня для Вас плохие новости: она Вам изменила. Она так и называлась — «наклейка защиты записи».
С изолентой есть нюанс: синаяя обычно ИК‑диодом просвечивалась насквозь, поэтому брали либо чёрную, либо подкладывали под синюю бумажку, чтобы наверняка.
На некоторых дисководах механика была, поэтому можно было и синей... ;-)
На некоторых дисководах механика была
На уровне баек говорят, что была, но если так, то это было сильно до меня. Сколько флоповодов через мои руки прошло — у всех была оптопара.
Реально встречались флоповоды с механической защитой от записи. Такие дисководы оставляли на наклейке характерный след при вставлении дискеты с оной. Но чаще все же встречались дисководы с оптическим датчиком.
А еще встречались дискаводы, которым было все равно, есть ли наклейка. Не могу гарантировать, что так не было задумано разработчиком, но полагаю, что защита просто была сломана.
Ну и про изоленту. Помнится, в коробке с 5.25" дискетами (если купить нераспечатанную) часто шла бумажка-самоклейка для этих самых наклеек (уже заботливо надрезаная, только отклеивай и прилепляй к дискете). На 3.5" уже была штатная шторка.
Да пофиг, linux, mac, windows, шминугс - слышишь, что головка hdd не остановилась, лампочка помигивает - нефиг жать reset)))
в коробке с 5.25" дискетами (если купить нераспечатанную) часто шла бумажка-самоклейка для этих самых наклеек (уже заботливо надрезаная, только отклеивай и прилепляй к дискете)
Да, но их было максимум 40 штук, и они кончались и терялись.
Хм, ЕМНИП, на данной картинке, ровно наоборот, запись разрешена
Это прямой угол кипит при 90 градусах на кассетах запись запрещается удалением язычка, а на дискетах наоборот.
вы с аудио кссетами спутали, там, да, надламывая язычок получается квадратное отверстие чтобы не стереть. здесь наоброт.
Довольно не редко подключаю внешний НЖМД-помойку к макоси. На слух прекрасно слышно, когда диск пишет или же ничего не делает. При извлечении всякий раз говорит, что диск кем-то там занят. Тыркаю тумблер питания — диск был извлечён неправильно. Пока ни единого разрыва ни одного файла не потерял (тьху-тьху)
На macOS это ж от файловой системы зависит. Как-то контейнер APFS в котором была резервная копия `Time Machine` и раздел данных, пришёл в невосстанавливаемое состояние (с помощью какой-то матери данные из раздела данных считать, но диск пришлось стереть и разметить по-новой).
Примерно с прошлого века с таким не встречался, что б по сбою питания диск превращался в полный кирпич. Но Apple APFS обновил воспоминания. 😉
Linux плевать хотел на то, что носитель съемный. Любая запись идет через страничный кэш ... Насколько я помню, udisks, который монтирует флешки в большинстве десктопных окружений, монтирует vfat с опцией flush, и драйвер из-за нее старается сбрасывать данные пораньше. Судя по тому, что я вижу в Dirty, спасает это не сильно.
Это ж у всех через страничный кэш, вопрос только в управлении им. Возможно, проблема Linux в разнообразии методов настройки, грубо говоря, бывает трудно понять как он настроен, а так же когда и что собирается делать дальше.
Но сам механизм параметра flush для файловой системы vfat выглядит рабочим:
$ cat /etc/debian_version
13.7
$ #### async ####
$ sudo mount -o async,uid=1000,gid=1000 /dev/sdb1 /mnt
$ (set -x; mount | grep /mnt ; grep Dirty /proc/meminfo ; rm /mnt/tmp/tf.tmp ; time dd if=/dev/zero of=/mnt/tmp/tf.tmp count=512 bs=1048576 ; grep Dirty /proc/meminfo ; time sync ; grep Dirt /proc/meminfo)
+ mount
+ grep /mnt
/dev/sdb1 on /mnt type vfat (rw,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
+ grep Dirty /proc/meminfo
Dirty: 0 kB
+ rm /mnt/tmp/tf.tmp
+ dd if=/dev/zero of=/mnt/tmp/tf.tmp count=512 bs=1048576
512+0 records in
512+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 49,2342 s, 10,9 MB/s
real 0m49,236s
user 0m0,000s
sys 0m0,828s
+ grep Dirty /proc/meminfo
Dirty: 305416 kB
+ sync
real 1m4,861s
user 0m0,002s
sys 0m0,000s
+ grep Dirt /proc/meminfo
Dirty: 32 kB
$ sudo umount /dev/sdb1
$ #### flush ####
$ sudo mount -o flush,uid=1000,gid=1000 /dev/sdb1 /mnt
$ (set -x; mount | grep /mnt ; grep Dirty /proc/meminfo ; rm /mnt/tmp/tf.tmp ; time dd if=/dev/zero of=/mnt/tmp/tf.tmp count=512 bs=1048576 ; grep Dirty /proc/meminfo ; time sync ; grep Dirt /proc/meminfo)
+ mount
+ grep /mnt
/dev/sdb1 on /mnt type vfat (rw,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,flush,errors=remount-ro)
+ grep Dirty /proc/meminfo
Dirty: 12 kB
+ rm /mnt/tmp/tf.tmp
+ dd if=/dev/zero of=/mnt/tmp/tf.tmp count=512 bs=1048576
512+0 records in
512+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 118,362 s, 4,5 MB/s
real 1m58,364s
user 0m0,010s
sys 0m1,009s
+ grep Dirty /proc/meminfo
Dirty: 0 kB
+ sync
real 0m0,002s
user 0m0,002s
sys 0m0,000s
+ grep Dirt /proc/meminfo
Dirty: 0 kBСущественная проблема флешек под Linux - файловая система exfat, у которой нет параметра flush. Так что, да, "кнопка извлечения в файловом менеджере", eject или unmount, в общем случае, для Linux необходимы.
В Windows можно отключить буферизацию сразу для всех съемных дисков и дергать флекшку сразу после копирования.
powershell:
Set-StorageBusCacheMode -InputObject (Get-StorageSubSystem) -ProvisioningMode WriteThrough
Обратно вернуть:
Set-StorageBusCacheMode -InputObject (Get-StorageSubSystem) -ProvisioningMode WriteBack
Обычная практика - при копировании на внешнее устройство после cp делать sync. Какие еще кнопки, какие треи?
потому что так учили еще в школьном компьютерном классе
Я думаю, тут есть более разумное объяснение: потому что так написано в инструкции (к флешке или к компьютеру). Понятно, что никто не читает инструкций, но это достаточно общеизвестное правило, примерно как не ставить горячее в холодильник. Зачем его нарушать без нужды?
а на Linux перед этим набираю sync
А на Linux есть виждет на рабочий стол или в панель задач для этого? Чтоб ничего не набирать.
А вам не кажется, что вся эта проблема не должна касаться пользователей и напрямую идет из корявых интерфейсов?
Если я вижу прогресс бар с копированием, вижу как он дополз до конца и закрылся, значит Я ДОЛЖЕН МОЧЬ выдернуть флешку и файлы там ДОЛЖНЫ БЫТЬ ЗАПИСАНЫ. Зачем мне как конечному пользователю думать про кеширование, что линкус там в фоне что то пишет - почините интерфейс и проблема ненужного "безопасного" извлечения отпадет сама собой.
Создание скрытых папок как делает Spotlight (или еще хуже Android - вообще ничего не скрывает, просто херачит новые папки чтоб ему было удобно читать флешку) - для этого тоже должен быть отдельный котел в аду. Открываешь в один момент влешку, в там вместо 2х документов для печати 48 папок,53 файла и все созданы не тобой. Я понимаю, компьютеру тяжело это писать в себя, ему удобнее писать на чужеродное устройство (бедняжка), но так и быть, отложим то решение на потом, когда компьютеры станут быстрыми (сейчас у них конечно нет на это ресурсов).
Для начала хотя бы починить прогресс бар и убрать костыль для конечного пользователя, а то не компьютер для нас работает, а мы для него (думаем как бы ему удобнее было, чтоб ничего он не потерял).
Все верно, вот только кроме вас, вашим устройством интересуются многие кто. В жизни так и происходит. Пользователь скопировал файл и выдернул флешку, а в это время системный процесс индексировал данные, антивирус проверял тучи забытых файлов на трояны (и в процессе проверки активно писал на диск распаковываемое)... В итоге - флешка убита
Кроме того окно копирования файлов в проводнике - это одно. я видел окна бекапа, которые завершались в момент завершения записи в кэш записи. И их не волновало, что кэш еще активно пишется
А с какой стати антивирус запросто так что-то пишет на устройство с ограниченным количеством циклов записи??
«Да, мы охренели. И чо?» (C)
Пользователи сами их ставят, а потом начинают им доверять... ;-(
Преамбула - я не отвечаю за все виды программ и их последние версии
Суть. Программа, работающая с файлами не особо знает (и может не интересоваться, где конкретно файл лежит. Тут есть нюансы, но в первом приближении). Создавать новые файлы на носителе не всегда возможно, плюс существует проблема их удаления и доступности кому не положено. А оперативки всегда мало. Выход. Открываем файл, в котором есть упакованные объекты и начинаем писать за его конец. После окончания проверки обрезаем файл и возвращаем на место атрибуты. Внешне ничего не менялось и пользователю не видно
Минимум один известный мне антивирус флешки убивал. Нет, не тот, о котором вы подумали. У него иные проблемы. Я мысли не читаю, я знаю статистику антивирусов, кого вспоминают первыми
что линкус там в фоне что то пишет - почините интерфейс и проблема ненужного "безопасного" извлечения отпадет сама собой.
только надо чинить системный интерфейс линукса, ака API. ибо так просто приложение не может узнать об окончании процесса записи системой
поправьте меня, если такое API есть
Есть такое API, для vfat есть параметр монтирования flush, но к нему есть вопросы. Кроме того, для exfat он отсутствует.
Хм, по POSIX есть fsync() и Linux его поддерживает. Однако, API этого уровня неудобно для файловых менеджеров, т.к. не учитывает разных ожиданий от работы съёмных и встроенных носителей.
А вот параметры монтирования тома, наверное, удобнее. Правда, похоже, в Linux для файловой системы vfat параметр flush влияет только на close() или типа того, т.е. прогресс бар оказывается неравномерным.
Возможно, было бы удобнее, если бы гарантировалось ожидание на write() при превышении заданного максимального времени для грязных страниц кэш, но это трудно точно формализовать.
как нам узнать, что запись физически завершилась?
Как вариант, можно из /proc узнать состояние кэш, но это тоже не очень удобно.
С фсинком было много проблем, ТЛДР - не особо то он что то гарантирует, надо еще адекватный драйвер ФС и железо.
это настолько очевидный путь, что стоит посмотреть его наличие в приложениях, где возврат прогрессбара 100% ранее факта записи
Ну, fsync()/fdatasync(), как бы, да - тормоза. Хотя, кто знает, если их особым образом делать из отдельного потока с прогресс баром, то возможно, что и не такие уж и большие тормоза?
Впрочем, параметр flush и/или настройки от @Geth (https://habr.com/ru/articles/1087030/comments/#comment_30472288) могут более-менее починить прогресс бар в общем случае.
Тогда начать предлагаю с записи в оперативную память. А то там тоже повсюду костыли в виде кешей придумали, записал что-то в одном потоке, а в другом читаешь - нет ничего в памяти.
А если серьёзно - ну не будет оно так работать. Сегодня прогресс бар кому-то хочется, чтобы заканчивался когда запись кончилась, завтра - чтобы каждый файл появлялся по очереди и если выдернул на файле под номером 42, то предыдущие 41 должны быть высечены в кремнии.
Выдёргивать сам компьютер пока он работает из питания ведь никто не пытается (а если пытается то ссзб), а тут почему-то хочется сразу.
Выдёргивание в ходе работы или явно отображаемого копирования - это в любом случае нарушение транзакции, тут некорректно претензии предъявлять системе (хотя и такого любители найдутся).
Но прогресс-бар-то? Именно тот, который юзеру показывается? На кой чорт он вообще нужен, если не показывает успешное завершение транзакции целиком, со всеми внутренними процессами, её обеспечивающими?
Прогресс бар показывает, когда записанный файл можно открыть и он корректно полностью прочитается.
Тут я улыбнулся. Прогрес бар показывает, когда ПРОГРАММИСТ считает, что процесс завершен. Случай из практики. Работаем с 200 миллионами файлов. Прогрес-бар давно добежал, заказчик обрывает трубку. На деле файлы удалялись еще толи час, толи два. Ну не подумала разработка, что операция, которая для малого количества файлов занимает миллисекунды, в реальности займет час
Он нужен, так как заказчик хочет видеть прогресс и не зависла ли программа, работающая уже месяц по переносу данных.
Тертически он нужен и для того, что вы написали, но по факту этим не заморачиваются
Если я вижу прогресс бар с копированием, вижу как он дополз до конца и закрылся, значит Я ДОЛЖЕН МОЧЬ выдернуть флешку и файлы там ДОЛЖНЫ БЫТЬ ЗАПИСАНЫ. Зачем мне как конечному пользователю думать про кеширование
не компьютер для нас работает, а мы для него (думаем как бы ему удобнее было, чтоб ничего он не потерял).
Полностью согласен. Но как это совместить со следующим:
вашим устройством интересуются многие кто. В жизни так и происходит. Пользователь скопировал файл и выдернул флешку, а в это время системный процесс индексировал данные, антивирус проверял тучи забытых файлов на трояны (и в процессе проверки активно писал на диск распаковываемое)
Это ведь тоже в общем-то для удобства пользователя делается...
По моим ощущениям, человек становится придатком всех этих гаджетов - уйма времени уходит на обслуживание, настройку, разборки "как это работает" и т.д.
Возможно, интерфейсы взаимодействия человека и машины ушли куда-то не туда на уровне идеологии и пока что разворачиваться лицом к человеку не собираются.
интерфейсы взаимодействия человека и машины ушли куда-то не туда на уровне идеологии
Всё так. Потому что по-хорошему для съёмных носителей следовало бы предусмотреть 2 режима: юзер с ним что-то делает (и видит свои действия!), и юзер его оставил в покое.
И все фоновые изменяющие действия имеет смысл делать (или разрешать делать, если про уровень ОС говорить) только в те минуты, когда, грубо говоря, прогресс-бар ползёт.
Да, это с технической точки зрения противоестественно: либо мы замедлим юзерский процесс, либо у нас будет минимальный бюджет времени на наши действия в каких-то микропаузах.
Но второй режим, покоя, подразумевает, что пользователь может выдернуть носитель в любой момент. Хоть сразу после доползания прогресс-бара, хоть после часов ничего-не-делания. И на потенциально разрушающие действия в этом режиме должно быть табу.
Все же эти кнопки безопасного извлечения - это перекладывание проблемы с больной головы на здоровую.
Не согласен. Мне в первую очередь важно чтобы файлы быстро сбросились, а вся остальная активность побоку. Нажать кнопку безопасного извлечения, не переломлюсь.
И проблемы не было, пока на флешках был индикатор активности. Моргает, значит используй безопасное извлечение, нет, может рискнуть дёрнуть и так.
Зачем мне как конечному пользователю думать про кеширование, что линкус там в фоне что то пишет - почините интерфейс и проблема ненужного "безопасного" извлечения отпадет сама собой.
Ну Вы же винчестер из машины не выдёргиваете? Почему с флэшкой должно быть как-то иначе?
Жизнь слишком коротка для безопасного извлечения флэшек. ©
Ещё во времена дос навигатора она была коротка, прогрессбар было важно показать пользователю завершившимся как можно раньше.
Но таки диалоговые окна копирования были модальными, а система однозадачной. И пропажа с экрана диалога копирования файлов давала возможность работать дальше с фоновым копированием под капотом.
Для тех лет вполне себе решение.
у меня за все эти годы ни разу ничего не сломалось
Почему-то вспомнилось:
"Люди делятся на два вида: те, кто не делает бэкапы, и те, кто уже делает"
Я не знаю, как сейчас - но в околонулевые были материнки, которые могли сгореть при выдёргивании флешек (а иногда и втыкании). Также на некоторых материнках могли давать сбои по питанию, что вызывало перезагрузку, которая в win98 могла убить файловую систему уже на винте (что сам видел неоднократно), на xp убить файл реестра, загрузчик и сделать прочие мелкие неприятности.
А так да, если на флешку только что копировали, то безопасное извлечение на винде и sync на линуксах (может и ещё и umount), чтобы потом не думать где же эти файлы. Если торчит там пол дня и ничего не делает - ничего страшного и не будет.
Купил на озоне \ WB несколько флешек. Через месяц стали давать ошибки, после того как в windows попытался отформатировать - вообще не читаются. Какой есть софт под windows для низкоуровневого форматирования или чего подобное? Там вроде как нужно контроллер перепрошить на реальный объем памяти.
Флешки в windows всегда "с выдергиванием", но полагаю, что проблемы не из-за этого (другие из нормальных магазинов - работают). Еще были случаи полного убоя флешки, один из них: товарищ подарил недорогой переносной музыкальный проигрыватель (с USB), вставляю туда работающую флешку - она при первом же втыкании - сгорает (видимо), больше в нем использовать USB не стал.
Долговечность работы флешек (с учетом возросшего их объема) сильно просело. Скорее всего из-за падения спроса (облака и т.п.). "Дедовские" 2-4 Gb 10-15+ летние читаются норм, а современные дохнут через год плотного ежедневного использования. Только и остается как SSD в форм-факторе флешки.
Раз тут в комментариях про linux зашла речь, то может кому пригодится: В Linux можно выставить лимит для writeback cache (dirty pages) через
/sys/block/<device>/bdi/max_bytes и /sys/block/<device>/bdi/strict_limit
На своём ноутбуке добавил такое в udev:
ACTION=="add", KERNEL=="sd[a-z]", SUBSYSTEM=="block", ENV{ID_USB_TYPE}=="disk", RUN+="/bin/bash -c 'echo 1 > /sys/block/%k/bdi/strict_limit; echo 16777216 > /sys/block/%k/bdi/max_bytes'"
Автор странная. Проиграла спор, прочитала, что могут быть проблемы и продолжает делать тоже самое. Что делаете со всеми этими сэкономленными минутами?
на маке это отчасти решается форматированием в apfs которая от таких фокусов точно не умрет вся, максимум отдельный файл, но тогда конечно такая флешка на винде без доп софта не откроется
Как бы, APFS, по крайней мере, контейнер APFS может. Причём до состояния кирпича, считать ещё шансы есть, если очень очень постараться, но восстановить - нет, только переразметка.
Кроме того, бюджетные флешки не любят файловые системы с журналированием. Есть подозрение, что для флешек ExFAT - наиболее надёжный вариант под macOS.
Я проверила это самым простым способом: копировала на флешку папку с отпускными фотографиями, 1,2 ГБ в 340 файлах, и выдергивала ее посередине копирования, всего десять раз. Флешка пережила все десять, но каждый раз файл, который копировался в момент выдергивания, оказывался обрезанным или нулевой длины
Тезисно:
а) Если выдернуть флешку во время копирования, то копирование прервется, а часть файлов будет повреждена. Это очевидно;
б) Флешка переживёт десять и более выдергиваний. Да, при таком извлечении КЗ не происходит, в самой флешке отсутствуют подвижные компоненты. Это тоже очевидно.
Неясно в чем суть данного "эксперимента" или это еще одна "непридуманная история" сгенерирована нейросетью?
А что с android ? Например, если я смотрю фильм с флешки через приставку и выдергиваю флешку?
ну у меня вообще то мак ругается, а с виндой всё ок..
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Безопасное извлечение флешки стало ритуалом. Но только в Windows