Я не знаю о способе добавить вещи к /proc
за пределами записи модуля (или простой код ядра). Могли бы быть некоторые утилиты там все же.
Если можно создать и вставить модуль, то это довольно просто: можно просто создать другую символьную ссылку (/proc/mounts
уже символьная ссылка).
Источник (mnt_link.c
):
#include
#include
#include
#include
#define MODULE_VERS "0.0"
#define MODULE_NAME "mnt_link"
static int __init init_mnt_link(void)
{
static struct proc_dir_entry *symlink;
symlink = proc_symlink("mnt", NULL, "self/mounts");
if(!symlink)
return -ENOMEM;
return 0;
}
static void __exit cleanup_mnt_link(void)
{
remove_proc_entry("mnt", NULL);
}
module_init(init_mnt_link);
module_exit(cleanup_mnt_link);
MODULE_AUTHOR("U&L");
MODULE_LICENSE("CC-WIKI");
MODULE_DESCRIPTION("Create a /proc/mnt symlink to /proc/self/mounts");
Make-файл:
obj-m := mnt_link.o
KDIR := /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)
default:
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
(Это предполагает, что Вы будете создавать для своей существующей системы Linux. Для создания чего-то для Android можно обратиться к: Как Вы создаете загружаемый модуль ядра для Android?.)
После того как Вы загрузили модуль (insmod mnt_link.ko
), необходимо добраться:
$ ls -l /proc/m*nt*
lrwxrwxrwx 1 root root 11 Nov 27 22:43 /proc/mnt -> self/mounts
lrwxrwxrwx 1 root root 11 Nov 27 22:43 /proc/mounts -> self/mounts
Однако та ваша утилита могла бы очень хорошо ожидать что-то еще, чем эта символьная ссылка. (Возможно, это зависит от другого модуля, загружаемого для предоставления некоторой информации в том местоположении.)
Полномочия файла действительно не применяются к корню: Программы, работающие как корень, могут считать и записать файлы независимо от настроек защиты. (Однако даже корень не может выполнить файл, если один из выполнить битов не установлен; это не имеет значения который). Это объясняет почему cat
может сделать это. Но по-видимому, rsync
осуществляет его собственную проверку для обуздывания то, что могло бы быть скопировано. Таким образом, это не "ограничение", но предназначенное поведение (не, что это - любое утешение Вам). Я говорю, "по-видимому", потому что я не нашел документации для этого поведения.
(Извинения, если я просто вновь заявляю о Вашем вопросе! Не совсем уверенный из Вашего описания.)
Если бы Ваша проблема ограничена теневыми файлами, я был бы склонен добавить вызов к cat
к Вашему резервному сценарию, и игнорируют rsync
ошибка для этих файлов. Вы могли добавить логику, чтобы только синхронизировать теневые файлы, когда они изменились, но действительно они являются достаточно маленькими, который я не побеспокоил бы.
Я не могу сказать Вам точно, почему Ваш rsync перестал работать, потому что rsync копируют работы в моих системах.
Однако я могу дать Вам рецепт для определения, почему rsync перестал работать. Как базируются на сервере, который будет сохранен:
cd /tmp
echo foo > tst
chmod 0000 tst
strace -fo strace-cat.out \
cat tst
strace -fo strace-rsync.out \
rsync -av --quiet tst tst.2
# set RSYNC_OPTS and hostname before executing following
strace -fo strace-remote-rsync.out \
rsync $RSYNC_OPTS --quiet tst 192.168.25.6:/tmp/tst.3
Это разделяет проблему на три части - успешное локальное открывается/читает/закрывает для кошки, локальный rsync (который мог бы успешно выполниться), и удаленный rsync, который перестанет работать, как Ваш делает.
Вы сможете видеть от вывода strace в strace-remote-rsync.out (и возможно strace-rsync.out), какой системный вызов перестал работать. И Вы будете видеть, что rsync является намного более сложной операцией с подпроцессами и другим вводом-выводом. Это использует mmap (2), чтобы загрузить файл в память, вместо того, чтобы открыть (2) для получения дескриптора файла для него.