>>211517
Total Commander

robocopy под оффтопиком, rsync.

>>211519
Так ведь Total Commander перебивает даты, или как-то можно?

>>211528
Explorer с ntfs на ntfs не перебивает точно.

>>211517
При помощи UltraISO под маздаем или dd в никсах рипаешь образ харда с древней файлопомойки и прожигаешь его на новый хард.
Для рипа у тебя должно быть столько свободного места на харде твоего компа, на сколько гигабайт создан раздел/сам хард, если их более одного, а для прожига хард должен быть объём более, чем рипнутый образ.

>>211528

>>211534
Спасибо за конкретный ответ.
Вообще это вроде-как свойство файловой системы, и ей как-то до лампочки что ты как пользователь перемещаешь а не копируешь, технически копируешь значит копируешь.
Вообще есть программы которыми можно вручную перебить даты, я на вскидку не назову погуглите если интересно.

>>211528

Не знаю, откуда взялась идея «Total Commander перебивает даты». Всегда при копировании копируется и дата файла, а не то простые программы защиты от копирования были бы ещё проще (им достаточно было бы проверять дату).

>>211517
Я предлагаю Акронис

True Image или Disk Director --- выбирай сам

тест

В общем в итоге я диск с древней файловой помойкой клонировал Акронисом.
Был ещё второй с торрентами его я перенёс FreeFileSync.
Total Commander почему-то всё равно перебивает даты.

>>211615

>Акронисом

Какой конкретно утилитой? У него их много и почти все так или иначе с диском работают.

>>211618
Acronis True Image, инструмент клонирование диска.

>>211517
https://www.howtoforge.com/tutorial/linux-dd-command-clone-disk-practical-example/

По треду видно. Как всегда у сидящих на альтернативной ОС нужны костыли и велосипеды.

>>211623
Философия виндоус, если я не ошибаюсь, долгое время заключалась в том, что весь стандартный софт включая даже шел, нужно будет заменить на сторонние продукты. Впрочем, сейчас уже не то время чтобы спорить какая OS лучше. Как по мне все они превратились примерно в одинаковые горы индусского добра, подпёртые палками чтоб не развалились под собственной тяжестью.

>>211517
Из-под линукса, можно с liveCD, под рутом:
cat /dev/sda > /dev/sdb
И потом
sync
Не забудь указать правильные имена дисков и трижды перепроверь.
Потом поставь диск в систему и по вкусу расширь раздел на новом диске штатными графическими средствами ос, если новый диск больше старого.

>>211632
dd if=/dev/sda of=/dev/sdb bs=16MiB status=progress все-таки будет правильнее использовать. Либо даже ddrescue, если есть желание иметь возможность записать лог, прервать и продолжит копирование.
Оно и быстрее, и надежнее. cat по своей природе предназначен больше для обработки текстовых файлов.

Но еще стоит внимание обратить на то, что в таком случае копируется не один раздел, а весь диск и если на диске используется таблица типа GPT, то будут проблемы, если размер дисков отличается, так как у GPT есть вторая таблица в конце диска. Для GPT после копирования на больший диск нужно сделать sgdisk --move-second-header.

Ну, и конечно стоит понимать, что если в файловой системе есть свободное место, то даже для переноса всей файловой системы может быть значительно эффективнее использовать утилиты вроде ntfsclone, btrfs replace, partclone и так далее.

>>214470

> умеет дефрагментировать диск полностью

Тут только загрузившись с Live CD / USB, а в противном случае не получится дефрагментировать системные некоторые файлы.

> дефрагментировать диск полностью
> и не затрачивать на это по нескольку суток к ряду

Тут от самого железа зависит — объёма харда и скорости чтения / записи.

> А то из всего что попадалось, современные софтины только и умеют что перезаписывать диск заново. В лучшем случае сортируя при этом файлы. На этом фоне стандартные дефрагментаторы выглядят не так уж плохо.

Эм… Дефрагментация же и есть просто упорядоченная перезапись файлов.

>>214470
Зачем это вообще нужно на современных дисках? Ощутимый прирост получишь только в очень специфичных случаях. Для мерзкой NTFS хватит дефрагментации MFT, для нормальных CoW - вообще не надо дергаться.

Скорее наоборот проблем огребешь с черепицей. У тебя же не дорогой серверный диск?

>>214474

> Только там где одни программы справляются за часы, другие тратят дни.

Стандартная утилита из Windows справляется с дефрагментацией диска на пол терабайта за 3–4 часа, а иногда и меньше, при совершении этого процесса раз в два месяца.

> Лучше уж тогда прикупить внешний диск и гонять файлы туда-обратно вместо дефрагментации
> а проблем на порядок меньше

Внешние жёсткие диски обычно сильно греются при длительной работе.

>>214476

> Правда не потому что они такие хорошие, а из-за качества альтернатив.

Always has been. В сторонних дефрагментаторах никогда не было смысла, ибо стандартного dfr.exe вполне достаточно для своих задач, если рассматривать Windows, конечно.

>>214479
Ох не думал я что ещё доживу до обсуждения дефрагментаторов и того, нужны ли программы, не использующие defragAPI (или как оно там зовётся). Я думал, это всё закончилось со временами WinXP.

>>214481

> Или изобретением стабильных файловых систем не подверженных фрагментации.

Достаточно вылезти из windows-мирка - и все становится радужно. Почти.

>>214481

> Закончится оно только с тотальным переходом на накопители со свободным доступом к произвольным ячейкам памяти. Например SSD. Или изобретением стабильных файловых систем не подверженных фрагментации. Скорее первое.

SMR-механика тоже не слишком позитивно относится к дефрагментации, CMR уже исчез в 2.5" формфакторе, а дефрагментация многотерабайтной файлопомойки выглядит довольно сомнительным занятием. Дефрагментация морально устарела как явление 5 лет назад.

>>214516
Про специальную "автодефрагментацию" SMR слышу в первый раз. Скорее всего ты смешал в кучу собственно дефрагментацию и процесс записи на SMR - когда диск для дозаписи данных читает целый большой блок, а потом заново его пишет в новое место. Что процесс дефрагментации определенно напоминает.

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

Господа, простите великодушно мне резкое заявление. Однако, SMR — рак.

>>214523
Ровно в такой формулировке - не утверждалось. Утверждалось, что сама проблема фрагментации сейчас не так актуальна, как лет 20 назад. Диски стали достаточно быстрыми и умными, файловые системы не отстают (горячий привет NTFS, хе-хе).

К тому же, место HDD в задачах, включающих в себя много случайного чтения-записи, заняли SSD. В линейном же режиме выигрыш от дефрага всегда был небольшим.
Дефрагментировать десятки часов многотеррабайтную помойку ради выигрыша в пару MBPS удовольствие сомнительное.

>при которой модифицированный блок (лента)

окончательно

>перезаписывается в соседнюю пустую ячейку (ленту), старая не меняясь помечается для внутренней логики как содержащая одни нули (пустая), а позднее

на нее записывается новый блок данных. Именно так SMR и работает.

Склонен считать, что эти "некоторые" натянули сову на глобус.

>данные в буфере (иногда уточняется, что в силу естественных причин) дефрагментируются

Данные в буфере не обрабатываются, иначе это не буфер.

А что произойдет, если у SMR-диска, натужно в "свободное" время разгребающего записанное (ведь ОС уже полагает, что операция записи полностью завершилась), внезапно пропадёт питание?

>>214532
Data loss с неплохой вероятностью.

И это источник отдельной боли ниже спины.

>>214537
Не будет никакой потери данных.

Контроллер SMR диска по умолчанию пишет в быстрый не-SMR буфер размером несколько десятков гигабайт. Когда место в буфере кончается, контроллер вынужден начинать писать непосредственно в SMR. Это в целом тоже не проблема, пока есть полностью свободные зоны. А когда свободные зоны с кэшем кончаются и диску надо переписывать уже имеющиеся данные, начинается веселье вида последовательной записи со скоростью в 1-2МБ/с. По крайней мере, так себя ведут сигейты.

>>214540
Нет, будет. При перемещении данных из кеша на постоянное место хранения при условии закончившегося кеша и записи на дальние области пластин. Запаса питания на дозапись и парковку может не хватить, поскольку число элементарных операций значительно больше, чем в CMR.

>>214546

>При перемещении данных из кеша на постоянное место хранения

Невозможно переместить данные из кэша. Можно их прочитать в буферную память, прочитать туда же содержимое зоны SMR куда они должны быть записаны, произвести перезапись зоны теми данными что лежат в буфере, обновить таблицу местоположения блоков, и только после этого можно будет перезаписать данные в кэше чем-нибудь другим.