сказ об том как rsync грохнул мне ntfs раздел

Забанься, рукожоп.

rsync двигать разделы... не, ну идея классная, вот с реализацией пока ещё траблы, но мы работаем над этим...

в чём смысл удаления раздела?

и напоследок «всё есть файл», но не все файлы «одинаково полезны»

Отмонтировать пробовал? Снять флаг занятости (или как там его?)?

вот видео https://streamable.com/bljfe

Не открывается.

Подозреваю, что запустив rsync с опцией -a, которая подразумевает --devices, вы заменили файл устройства /dev/sdb3 файлом устройства /dev/sda1 (не содержимым!), в результате чего оба этих файла, имея одинаковые major и minor, стали указывать на один и тот же раздел. Поэтому попытавшись затем удалить /dev/sdb3 в GParted, вы грохнули /dev/sda1.

Перед нами классический случай ущемления дверью гениталий.

Знаешь Миша, а можно еще хер себе дверью специально прищемить и потом всем рассказывать про неправильные двери.

Sun-ch (*) (06.03.2006 19:56:09)

root@deepforest-P31-DS3L:/home/deepforest# rsync -avh /dev/sda1 /dev/sdb3

Эталонный ССЗБ.

Не ну, rsync тоже «хороша», что тут такое факап может случиться из описания опций абсолютно неочевидно.

неочевидно? он делает rsync прямо на файлах устройств, не на примонтированных файловых системах. по-моему, тут все более, чем очевидно.

в результате чего оба этих файла, имея одинаковые major и minor, стали указывать на один и тот же раздел.

Проблема в том, что сообразить такой факт трудно просто читая описание опций. Я бы если бы для этой цели использовал rsync подумал бы, что оно как dd сработает, а опция "-а" заменяет несколько других.

Это нам очевидно, а человек просто думал, что вот одно устройство с файлами, вот - другое и давай копировать одно в другое. Если бы rsync тупо скопировал содержимое, то все бы получилось. Хотя для этого логично dd использовать.

rsync -avh /dev/sda1 /dev/sdb3

Что это за заклинание у тебя? Ты тролишь так?

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

rsync с libastral пока не слинкован, узнать о ваших фантазиях не умеет.

rsync -avh /dev/sda1 /dev/sdb3

лол

Тебе, кстати, надо еще открыть для себя значение знака / и разницу между rsync -a /dev/dir1 /dev/dir2 и rsync -a /dev/dir1/ /dev/dir2/

Грубо говоря, он хотел файл А положить внутрь файла Б. А что там находится как бы и неважно. Непроканало, из Б сделался симлинк на А.

И вот факт, что Б теперь симлинк, а не отдельный файл устройства он точно не совсем понятен сходу без опыта администрирования хотя бы локалхоста.

Он не работал с файлами, он работал с блочными устройствами. Это другой этаж.

Кстати, народ, уточните, а в какой момент блочное устройство превращается в ФС? Сразу после монтирования?

Что-то я теперь тоже запутался.

Я так понял, что rsync тупо линк сделала на /dev/sda1, который стал называться /dev/sdb3 и когда он его удалил, удалился и «исходный» файл. По идее, сейчас самый простой способ все (по крайней мере /dev/sda1) восстановить - это банально reset сделать.

Или что тогда там произошло?

во-первых, Б не симлинк

во-вторых, если он просто «хотел файл А положить внутрь файла Б», то непонятно, зачем вообще включать ключ "-a"

в-третьих, давайте-ка не будем гадать, чего хотел сделать ТС. Если включил ключ "-a", значит, как минимум думал о рекурсивном обходе файловой системы, а вовсе не о том, чтобы скопировать один файл в другой

Вы вообще часто отдельные файлы копируете рсинком, а не cp или cat?

Я так понял, что rsync тупо линк сделала на /dev/sda1

я, чесна гря, понятия не имею какое будет поведение у rsync при работе с блочными устройствами. /dev/sda1 разве может называться словом «файл»?

А расскажи подробнее, как оно в таком случае вообще работает.

во-первых, Б не симлинк

Вообще да, хотя по смыслу скорее хардлинк.

Вы вообще часто отдельные файлы копируете рсинком, а не cp или cat?

Нет естественно. Но и сообразить, что такая фигня получится из опции -а признаюсь сразу бы не сообразил. Применил бы он не на девайсах, а примонтированных системах, отработало бы вполне нормально (с ntfs конечно в любом случае не нормально, так как она полностью не поддерживается).

я, чесна гря, понятия не имею какое будет поведение у rsync при работе с блочными устройствами.

Мне тоже стало интересно. Просто бы в голову не пришло запустить rsync на них, но раз кто-то запустил интересно.

/dev/sda1 разве может называться словом «файл»?

Может вообще-то, его и открыть на запись/чтение можно как файл

Может вообще-то, его и открыть на запись/чтение можно как файл

покажи пример, как это сделать?

cat /dev/sda1 например.

rsync -avh /dev/sda1 /dev/sdb3

Земля тебе пухом

Стоп, минуточку, cat работает с примонтированной ФС, в рамках которой существует файл, указывающий на устройство /dev/sda1. Но этот факт не делает устройство /dev/sda1 файлом.

/dev/sda1 разве может называться словом «файл»?

«ну рэбята, ну же...» Конечно, файл — файл блочного устройства.

С точки зрения системных вызовов man 2 open, man 2 read, man 2 write - /dev/sda1 - файл, который можно открыть, читать и писать в него. cat /dev/sda1 выводит на консоль содержимое /dev/sda1 в сыром виде

- dd? Нет, не слышал...
A-a-a-a!!!

Ага, вот в этом, видимо, всё дело. Формально, файл блочного устройства является файлом, но работать с ним надо соответствующими инструментами. В их число входит rsync?

cat /dev/sda1 > some_file сделает тебе образ диска. Это файл. Считай его образом диска который постоянно меняется.

Марш спать! Или прекрати тупить.

С этим ясно. Что конкретно ТС сделал не так?

# rsync -avh /dev/sda1 /dev/sdb3

Реально поржал. Такого я еще не видел.
Это же еще надо до такого додуматься.

Эпический...

Формально, файл блочного устройства является файлом, но работать с ним надо соответствующими инструментами.

Можно и обычными, если не нужны специфические фичи.

В их число входит rsync?

А вот этого я в итоге тоже не понял.

Кто-нибудь, распишите как именно это отработало.

когда rsync не подсовываешь ключ -a, он его пропустит. когда подсовываешь - он создаст новое блочное устройство с той же парой major-minor, что и у исходного. Да ведь в начале темы уже написали об этом!

запустив rsync с опцией -a, которая подразумевает --devices, вы заменили файл устройства /dev/sdb3 файлом устройства /dev/sda1 (не содержимым!), в результате чего оба этих файла, имея одинаковые major и minor, стали указывать на один и тот же раздел.

а, всё, дошло. praseodim он скопировал файл блочного устройства, который указывает на /dev/sda1, в файл блочного устройства, который указывал на /dev/sdb3. То есть, оба файла стали указывать на одно и то же блочное устройство. Он не содержимое скопировал, он указатель скопировал один на другой.

Да, спасибо, пропустил то сообщение.

когда подсовываешь - он создаст новое блочное устройство с той же парой major-minor, что и у исходного.

Вот это как-то не сразу из описания понятно.

rsync --help

-a, --archive               archive mode; equals -rlptgoD (no -H,-A,-X)
-r, --recursive             recurse into directories
-l, --links                 copy symlinks as symlinks
-p, --perms                 preserve permissions
-t, --times                 preserve modification times
-g, --group                 preserve group
-o, --owner                 preserve owner (super-user only)
-D                          same as --devices --specials

--devices               preserve device files (super-user only)
--specials              preserve special files

Как я понимаю, тописктартер внимательно не разбирался, что такое preserve device, на автомате подумал, что это просто как и все остальное там права разные юзеров с группами сохраняет.

Если бы не -D входящее в -a то ничего бы плохого не случилось, как я понял.

То есть, без -a должно было нормально сработать?

Без "-a" он бы просто ничего не делал!

Почему? Чем это отличалось бы от dd?

Он бы пропустил файл блочного устройство и написал «пропускаю необычный файл»! Тебе сложно самому потестить? Наделай себе блочных девайсов и рсинкай их до посинения!

Так, то есть, получается, что без ключа -a оно бы пропустило, а с ключем -a оно скопировало как скопировало. Значит ли это, что rsync не подходит для операций копирования содержимого блочного устройства?

Да, но только потому, что он знает о существовании этих самых устройств. dd и cat не знают, поэтому ими можно. Из кода rsync при желании тоже можно вырезать эту часть, где он MAKEDEV по протоколу передает, пусть себе копирует блочное устройство, пока оно не кончится.

Спасибо, это хорошее знание.

Как я понимаю, тописктартер внимательно не разбирался, что такое preserve device, на автомате подумал, что это просто как и все остальное там права разные юзеров с группами сохраняет.

Да, а там ВНЕЗАПНО https://github.com/AndyA/rsync/blob/9d96ce6a626bda1cd5df866e66159e75782df6f5/...

static int try_dests_non(struct file_struct *file, char *fname, int ndx,
			 char *cmpbuf, stat_x *sxp, int itemizing,
			 enum logcode code)
{

.....
skipped
.....
		case TYPE_DEVICE:
			devp = F_RDEV_P(file);
			if (sxp->st.st_rdev != MAKEDEV(DEV_MAJOR(devp), DEV_MINOR(devp)))
				continue;
			break;

и https://github.com/AndyA/rsync/blob/9d96ce6a626bda1cd5df866e66159e75782df6f5/...

	if ((am_root && preserve_devices && IS_DEVICE(file->mode))
	 || (preserve_specials && IS_SPECIAL(file->mode))) {
		dev_t rdev;
		int del_for_flag = 0;
		if (IS_DEVICE(file->mode)) {
			uint32 *devp = F_RDEV_P(file);
			rdev = MAKEDEV(DEV_MAJOR(devp), DEV_MINOR(devp));
		} 

Вот такой вот неожиданный (если не зная матчасти применять инструмент) rsync.

Да, с этим работать как с обычным файлом.

Завещай свой мозг науке, пожалуйста. Изучение твоих отклонений может спасти множество файловых систем.