Использование обновления recollindex для файлов резервных копий
У нас та же проблема с использованием gradle через конвейер jenkins build -.
Я вручную скомпилировал glibc 2.14 в /opt/glibc -2.14. Если я установил LD _LIBRARY _PATH, android sdk работает нормально, но вызов сборки gradle завершается с ошибкой «futex» (, видимой на strace ).
Нет вывода даже при запуске gradle с параметром stacktrace.
Единственный способ запустить gradle — установить следующие пакеты RPM с сайта redsleeve.org:
wget http://ftp.redsleeve.org/pub/steam/glibc-2.15-60.el6.x86_64.rpm
wget http://ftp.redsleeve.org/pub/steam/glibc-common-2.15-60.el6.x86_64.rpm
wget http://ftp.redsleeve.org/pub/steam/glibc-devel-2.15-60.el6.x86_64.rpm
wget http://ftp.redsleeve.org/pub/steam/glibc-headers-2.15-60.el6.x86_64.rpm
rpm -Uvh glibc-2.15-60.el6.x86_64.rpm glibc-common-2.15-60.el6.x86_64.rpm glibc-devel-2.15-60.el6.x86_64.rpm glibc-headers-2.15-60.el6.x86_64.rpm
После установки обновленных пакетов glibc -сборка gradle работала нормально в системе CentOS 6.9 (x64 ).
Это хорошо для среды тестирования, но в случае обновлений системы -это может нарушить всю процедуру обновления. Я пытаюсь найти лучший способ, используя скомпилированную вручную версию.
~Ура
Использование recollindexдля проверки изменений в файлах — интересная идея. но в этом нет необходимости, если я понимаю ваш вариант использования -. Rclone уже смотрит на размер файла и время модификации решать, что обновлять:
Normally rclone will look at modification time and size of files to see if they are equal. If you set this flag then rclone will check the file hash and size to determine if files are equal.
По сути, это то же самое, что и recollindex.
Use mtime instead of ctime to test if a file has been modified. The time is used in addition to the size, which is always used.
Подробнее см. здесь исходный код:
// File signature and up to date check. The sig is based on
// m/ctime and size and the possibly new value is checked against
// the stored one.
Итак, rcloneвыполняет по существу то же сравнение, что и recollindex, за исключением того, что вместо обновления индекса rcloneобновляет удаленную резервную копию. Вы можете просто запустить rcloneтак же, как вы сейчас запускаете recollindex.
Кроме того, использование индекса recoll для определения того, что нуждается в резервном копировании будет иметь ряд недостатков, таких как:
В зависимости от записи
skippedNamesв~/.recoll/recoll.conf, recollindex пропустит индексирование многих файлов, таких как файлы PNG и JPEG. Предположительно, вы захотите сделать резервную копию этих файлов.Индекс не отражает текущее состояние файловой системы; на самом деле, файловая система, скорее всего, изменилась во время работы
recollindex. Таким образом, индекс нельзя использовать как надежный способ решить, что нужно обновить.
Кстати, при запуске в режиме мониторинга в реальном времени recoll не делает ничего особенного для обнаружения изменений; он использует Inotify или FAM/GAMIN за кулисами. Вот ссылка на соответствующую часть исходного кода, если вам интересно:
Скрипт recoll_status.pyпросто опрашивает ~/.recoll/idxstatus.txt. Здесь не будет полного списка измененных файлов,либо; он просто показывает, какой файл в данный момент индексируется, и только время от времени обновляется, а не для каждого отдельного файла.
// Update the status file. Avoid doing it too often. Always do
// it at the end (status DONE)