From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <41CFD18E.3000708@delin.ru> Date: Mon, 27 Dec 2004 12:10:38 +0300 From: fmfm User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; ru-RU; rv:1.7.4) Gecko/20040926 X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: ALT Linux Sisyphus discussion list Subject: Re: [sisyphus] =?KOI8-R?Q?=C9=D3=D0=CF=CC=D8=DA=CF=D7=C1=CE=C9=C5?= =?KOI8-R?Q?_rsync?= References: <41CBE91C.1070703@delin.ru> <20041224100809.GA32654@basalt.office.altlinux.org> <41CC0463.2090201@delin.ru> <20041225171351.GA2586@nomad.office.altlinux.org> In-Reply-To: <20041225171351.GA2586@nomad.office.altlinux.org> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: sisyphus@altlinux.ru X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ALT Linux Sisyphus discussion list List-Id: ALT Linux Sisyphus discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2004 09:11:50 -0000 Archived-At: List-Archive: Dmitry V. Levin пишет: >>У меня синхронизация репозитория настроена примерно так. >> >>Имеются вспомогательный каталог для синхронизации и каталог рабочий. >>В "установившемся" состоянии в рабочем каталоге лежат реальные >>файлы, а в дополнительном - symlinks на них. >> >>Раньше, при синхронизации, rsync удалял устаревшие ссылки и загружал новые >>файлы. После этого у новых файлов проверялись md5sum и gpg sign. >>Если все OK, то файлы перемещались в "рабочий" репозиторий, замещаясь >>ссылками на них. Если нет, то перемещались в "карантин". >> >>Дополнительно, из рабочего каталога во временную "корзину" уходили >>файлы с удаленными ссылками. Это же "ядро" хорошо работает и с >>off-line синхронизацией от CD срезов Sysiphus. >> >> > >Немного другую схему, реализующую описанную выше задачу, можно посмотреть >на следующем примере: > >1. создаём модель: >$ mkdir src dst backup >$ touch src/same src/new dst/old >$ cp -a src/same dst/ >$ echo src >src/changed >$ echo dest >dst/changed > >2. готовим каталог для синхронизации: >$ cp -al dst new > >3. закачиваем: >$ rsync -rt src/ new/ --partial --delete-after --backup --backup-dir=$PWD/backup > >4. анализируем результат: >$ find backup -type f >backup/changed >backup/old >$ find new -type f -links 1 >new/changed >new/new >$ find new -type f -not -links 1 >new/same > > > Прошу прощения за длительный off-line Когда то этот код у меня работал с hardlink. Потом выяснилось, что это решение не может считаться универсальным и вот почему. Например, может быть несколько "рабочих" репозиториев с общими пакетами, которые являются hardlink. В этом случае выяснение вопроса "сколько hardlinks у пакета" без дополнительных уточнений не содержит всей необходимой информации. SymLinks, напротив, хорошо изолируют "рабочую" область от "загрузочной" при минимальных требованиях к дисковому пространству. Еще одна причина "неуниверсальности" hardlinks в следующем. С symlinks становится удобной загрузка вручную. Т.е. можно в mc удалить устаревшие ссылки и копировать новые пакеты в "загрузочной" области. Текущий промежуточный результат в mc виден "невооруженным" глазом. Когда все сделано, выполняется загрузочный сценарий (или наоборот, rollback). Изоляция областей - предпосылка для модульности кода. Например, код для off-line импорта со сменных CD процентов на 70 использует код для on-line синхронизации по сети. Как дополнение. Чтобы добавить возможность синхронизации на wget мне потребовалось дописать и протестировать только одну функцию (и добавить пункт в меню). Таким образом, неизменяемое --resolv-dst-symlinks=off в rsync это потеря функциональности. Владимир