1

У меня есть несколько устройств (сервер, башня, ноутбук, телефон Android). Я хочу, чтобы моя музыкальная библиотека была синхронизирована со всеми из них.
Так что я подумал о системе контроля версий, которая просто заботится о действиях CRUD (или, скорее, CRD). Возможно, он может отслеживать файлы, используя их первоначальное имя и отслеживая любое переименование или удаление.

Все популярное программное обеспечение, которое я знаю (git, svn, cvs, ...), не подлежит сомнению, потому что оно экономит слишком много накладных расходов (они различают двоичные файлы).
Потоковая передача также не работает для меня, потому что у меня не всегда есть подключение к интернету.
Синхронизация музыки с использованием таких инструментов, как unison, также очень неэффективна, потому что я записываю метаданные в файлы, чтобы их хэш-сумма, временная метка и размер постоянно менялись. Если есть инструмент сравнения или синхронизации, который игнорирует незначительные изменения в размере и игнорирует временную метку и разрешения и т.д., Это может быть хорошо, но я не знаю ни одного.

Любые другие креативные и изящные решения приветствуются.

2 ответа2

1

Вы можете настроить rsync таким образом, чтобы игнорировать уже существующие файлы, что предотвратит некоторые изменения в метаданных, которые вас беспокоят. Ваши опасения по поводу этого, вероятно, преувеличены. Если была изменена только небольшая часть файла, будет обновлена только эта часть; основной алгоритм rsync выяснит, что большинство из них одинаковы. Вы будете платить дополнительные издержки за чтение файлов по пути, но, возможно, вы могли бы использовать «--ignore-существующие» большую часть времени и использовать только более длинную форму синхронизации, которая пытается сортировать все изменения менее регулярно.

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

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

0

Раздельное копирование, обновление и удаление - используйте инструменты, которые хорошо справляются с одной задачей - я имею в виду, что это философия Unix, верно?

Я просто сохраняю стандартизированный набор тегов и файлов и синхронизирую их с «базовым» набором - вы можете просто использовать cp -u или другой инструмент копирования по вашему выбору - в моем случае у меня установлен мастер-файл в системе Windows и просто скопируйте файлы на место на USB-накопитель и используйте его для синхронизации других копий.

Если они устарели, сдуйте оригинал или используйте rsync или unison только тогда.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .