Это скорее всего не сработает.
Этот ответ может предполагать типичную настройку, где C: содержит операционную систему.
Позвольте мне начать с одного примера, почему вы не получите точную копию:
Причина № 1: Исследователь пытается быть хорошим
Когда вы используете GUI (проводник) Microsoft Windows для копирования изображения в новую папку, Windows попытается сделать для вас "удобную для пользователя" вещь. Он будет смотреть на картинку, делать миниатюру и сохранять ее в файле с именем thumbs.db
Так что, если вы копируете кучу файлов, и он начинается с ApicOne.jpg, затем с BpicTwo.jpg, а затем с CpicThree.jpg, он создает 3 эскиза, копируя эти три изображения.
Затем, когда он пытается скопировать старый файл thumbs.db (так как мы копируем все файлы), возникает конфликт, потому что более новый файл thumbs.db уже существует. В новом файле thumbs.db пока нет файла ZpicTwentySix.jpg (при условии, что файлы копируются в алфавитном порядке). Таким образом, графический интерфейс перестает копироваться, когда он спрашивает вас, хотите ли вы перезаписать существующий файл с именем thumbs.db
Простая реальность такова: это боль.
Теперь, теоретически, вы можете просто пропустить этот файл (и сохранить старый файл) или перезаписать старый файл, потому что новый файл должен содержать те же миниатюры (в конце концов, после того, как будет скопировано последнее изображение). Однако этот новый файл теперь будет иметь другую дату изменения. Итак, у вас нет точной копии. Кроме того, если файлы ранее сортировались другим способом (возможно, добавляются в каталог на основе даты файла, когда они были загружены с течением времени), но затем сортируются так, как Explorer копирует их (в алфавитном порядке), то, снова, вы не храните все точно так же.
Причина № 2: файлы могут не соответствовать тому, что они появляются
Некоторые файлы не существуют так, как они могут выглядеть. C:\Windows\WinSXS\ содержит так называемые "параллельные сборки". По сути, когда вы устанавливаете две программы, использующие общий файл, более новые версии Microsoft Windows сохраняют обе версии файла, даже если у них одинаковое имя файла. При обновлении файла Microsoft Windows может хранить как новый файл, так и старый файл. Методы такого рода улучшают совместимость, когда установлено несколько программных компонентов, и помогают возвращаться к предыдущему состоянию ("восстановление системы"), если возникают проблемы. Но способ, которым это реализовано, сложен.
Если вы запустите WinDirStat (скачанный со страницы WinDirStat, эта программа покажет вам размер файлов на вашем жестком диске). Каталог C:\Windows\WinSXS будет выглядеть массивно. Огромный.
Однако это будет неправильно. Смотрите, каталог WinSXS особенный. Каталог сообщит, что файл имеет определенный размер. Однако в действительности Windows использует некоторые специальные приемы с этой папкой. На самом деле в этой папке находится несколько частичных файлов, которые совместно используют некоторые данные. Я думаю. Что-то вроде того. Дело в том, что используются какие-то хитрости. И WinDirStat не понимает этих трюков. Таким образом, WinDirStat верит каждой лжи, которую ему говорит Windows, и WinDirStat в конечном итоге говорит, что файлы в каталоге WinSXS занимают абсолютно огромное количество дискового пространства.
Когда вы пытаетесь запустить программу, Windows достаточно умен, чтобы иметь возможность собирать части файла DLL и заставлять программу видеть копию любых необходимых данных, и поэтому программа работает просто отлично.
Когда вы используете GUI Explorer, чтобы просто попытаться скопировать этот каталог, функциональность "copy" GUI Explorer не понимает, что WinSXS является особенным. Таким образом, функция "копировать" будет пытаться скопировать каждый отдельный файл, как если бы он был целым файлом. Результатом будут файлы, скопированные в каталог назначения, который не обрабатывается специальным образом. Таким образом, пункт назначения не соответствует специальному источнику.
Причина № 3: Процесс загрузки может быть сложным
Загрузочный код может сделать некоторые интересные вещи. Разные версии разных операционных систем могут действовать по-разному, поэтому конкретные детали, которые я здесь упоминаю, могут не точно соответствовать конкретной версии Windows, которую вы используете. По сути, при запуске системы (BIOS / (U)EFI) будет проверен раздел диска с загрузочным кодом (MBR / GPT), который будет указывать на местоположение файла. Поймите, что на компьютере выполняется код, который может быть очень упрощенным. Этот упрощенный код может даже не полностью понимать сложные детали файловой системы. Например, он может не понимать соединение NTFS. Но это нормально. Возможно, загрузочный код понимает только то, что необходимый файл находится в секторе номер 6,189,247,145 диска. Когда операционная система установлена, операционная система помогает убедиться, что загрузочный код точно знает, где находится файл.
Если вы скопируете все файлы из своего корневого каталога (C:*. ) На новый диск (D:*.), Графический интерфейс Windows Explorer может сделать это очень простым способом, например, копирование данных в алфавитном порядке. Если ваша операционная система добавила файл (например, скрытый файл с именем C:\BootLog.txt), он может находиться перед C:\bootmgr (в алфавитном порядке). Таким образом, C:\bootmgr не появляется в списке файлов так же рано, как это было, когда Windows была установлена на диск C:\.
Это при условии, что MBR был правильно установлен на вторичном диске
Итак, вы понимаете, что MBR может понадобиться для поиска файла.
Теперь, как правило, задача загрузочного кода диска состоит в том, чтобы найти файл, который содержит более подробную информацию о том, как загрузить систему. Например, в Windows 95 эти данные обычно хранятся в файле \IO.SYS (но есть и другие имена файлов, которые также можно использовать вместо этого). В IBM PC DOS функциональность того же типа была сохранена в C:\IBMBIO.COM и C:\IBMBIO.SYS. Таким образом, было несколько загрузочных файлов, которые могли работать вместе.
Таким образом, проблема может распространяться только на MBR. Даже после запуска операционной системы загрузчик может иметь несколько "стадий", что может повлиять на несколько файлов. Я знаю, по крайней мере, одну операционную систему, которая документирует "загрузчик первого этапа" и "загрузчик второго уровня", не говоря уже о "ядре", которое запускается позже. Таким образом, забота о загрузке не ограничивается заботой только о начальном загрузочном секторе.
Причина № 4: данные могут быть использованы
Основная причина, по которой мне сказали, о том, что реестр не будет скопирован .. Но наверняка все на машине где-то файл?
Я бы не стал доверять этому. Я верю, что после запуска Windows она может сохранить часть реестра в памяти или в каком-либо файле кэша. Даже если реестр хранится на диске, некоторые из них могут находиться в другом файле (например, в файле "DataThatStillNeedsToBeWritten"), и текущая копия Windows может помнить: «У меня все еще есть данные, которые необходимо записать».
После того, как графический интерфейс Windows скопирует основные файлы реестра, Windows может выполнить некоторую работу, необходимую для перемещения данных, например, для перемещения данных из файла кэша (который в этом примере я назвал смешным именем "DataThatStillNeedsToBeWritten"). ") в основные файлы реестра.
Когда, когда графический пользовательский интерфейс Windows начинает копировать файл кэша "DataThatStillNeedsToBeWritten", в этом файле больше нет сведений, которые теперь скопированы в реестр.
Теперь, если ваш компьютер теряет питание, Windows часто восстанавливается довольно хорошо (возможно, с помощью запуска ChkDsk). Однако, когда вы копируете файлы, созданные на D:, некоторые важные данные, возможно, никогда не были успешно скопированы, и поэтому новая "копия" Windows может быть не в состоянии восстановиться так успешно.
Именно из-за этой концепции Microsoft разработала несколько сложных технологий, таких как Windows "Служба теневого копирования томов" (часто сокращенно обозначаемых как VSS или VSC; обе аббревиатуры используются для обозначения одного и того же). Такого рода проблемы вызывают то, почему программное обеспечение резервного копирования может захватывать "состояние системы", а популярные программные продукты для резервного копирования могут иметь специализированные подключаемые модули для взаимодействия с базами данных SQL и электронной почтой (поскольку такие данные часто хранятся в сети / могут использоваться и активно используются. используемый).
Комментарий
Обратите внимание, что я не говорю, что это единственные проблемы. Это лишь некоторые из них, которые быстро приходят мне в голову. Платформа Microsoft Windows значительно усложнилась с появлением новых версий. (XP была заметно сложнее, чем 2K/ME, XP Service Pack 2 также внесла заметную сложность, как и Vista, возможно, 7, конечно 8, и, основываясь на этом послужном списке, я уверен, что 10 тоже.) Так что я, вероятно, упускаю некоторые причины, тем более что более новые версии будут продолжать увеличивать сложность в будущем.
Решения
Два совета, чтобы помочь с этими проблемами:
- Если Windows загружалась с другого жесткого диска, то часто можно скопировать неактивную копию Windows, и при этом меньше проблем возникает.
- Программное обеспечение, которое поддерживает "снимок", часто имеет специальный код, чтобы попытаться принять во внимание многие из этих проблем.
