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

Есть инструмент ScanGear MP Ver. 3.10 для Linux доступен на веб-сайте Canon (, исходники, RPM и пакет Debian):

На сайте форумов пользователей Debian есть два практических руководства для серии Pixma MX490.



Серия PIXMA MX490 указана как «Непроверенная» на сайте проекта вменяемости, поэтому вполне возможно, что она вообще не работает с вменяемыми.

SANE :Поддерживаемые устройства

PIXMA MX490 Series USB WiFi 0x04a9/0x1787 Untested Testers needed!

нормальный -пиксма.5

The following models may use the same Pixma protocol as those listed above, but have not yet been reported to work (or not). They are declared in the backend so that they get recognized and activated. Feedback in the sane-devel mailing list welcome.

      PIXMA E400, E460, E470, E480, E500, E510, E560, E600, E610
      PIXMA MG3000, MG4100, MG6500, MG6600, MG6800, MG6900, MG8100
      PIXMA MP375R, MP493, MP495, MP740
      PIXMA MX320, MX390, MX430, MX450, MX490, MX710

0
21.03.2021, 11:32
2 ответа

Симлинк можно представить просто как текстовый файл, содержащий путь, на который он указывает. Целевой файл не обязательно должен существовать, чтобы это работало.

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

.
mkdir -p /var/www/mysite.example.com:80
cd /var/www/mysite.example.com:80
ln -s 'http://www.google.com:80/search?q=site:mysite.example.com' search.html

Означает, что Fnord ответит на запросhttp://mysite.example.com:80/search.htmlHTTP-перенаправлением в Google.

Таким образом, вполне возможно, что цель символической ссылки исчезнет.

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

Если вы спрашиваете о возможности наличия «dynlinks», то есть символических ссылок, которые динамически указывают на разные пути в зависимости от какой-либо переменной или условия (аналогично «точкам повторной обработки» NTFS в Windows NT ), эти существуют ли в некоторых Unices (см., например, Dragonfly BSD варианты символических ссылок ), но они не существуют ни в POSIX, ни в Linux.

2
28.04.2021, 22:58

Я думаю, что одним из очень простых способов было бы использованиеsshfs-монтирования, то есть просто монтирование каталогов сервера через ssh в локальный каталог pi. Затем вы можете просто указать там любые символические ссылки:

 mkdir /home/pi-user/serverlib
 sshfs user@server:/path/to/lib /home/pi-user/serverlib
 ln -s /home/pi-user/serverlib/programm_library.so.0.2

Существует несколько способов убедиться в том, что крепление существует так, как должно. (среди многих других вариантов):

  1. Поместите фиктивный файл i_am_unmountedв каталог. Если сетевое расположение смонтировано, тест [ -e /home/pi-user/serverlib/i_am_unmounted ]в сценарии завершится ошибкой. (используйте -o nonemptyвsshfs).

  2. Найдите удаленный каталог в выводе mount.

  3. Будьте более продуманными и сделайте все службы systemd, включая WOL, монтирование, проверку успешного монтирования и запуск обновлений файлов.

0
28.04.2021, 22:58

Теги

Похожие вопросы