Можем ли мы использовать жесткие ссылки Unix на смонтированном ресурсе Windows?

Question

Команда ln может создать жесткие ссылки на смонтированном общем ресурсе Windows, но cp -al завершается ошибкой. Это ожидаемое поведение? Я пытаюсь сэкономить место на диске, создавая копии в резервных копиях в стиле записи, используя cowdancer , rsync и cp -al .

backupuser@lan0:/mnt/backup/share$ mkdir a
backupuser@lan0:/mnt/backup/share$ touch a/b
backupuser@lan0:/mnt/backup/share$ cp -al a x
cp: cannot create hard link `x/b' to `a/b': No such file or directory
backupuser@lan0:/mnt/backup/share$ mkdir x
mkdir: cannot create directory `x': File exists
backupuser@lan0:/mnt/backup/share$ ln a/b x/b
backupuser@lan0:/mnt/backup/share$ ls -l x
total 0
-rwxr-xr-x 0 backupuser backupuser 0 Dec 23 17:33 b

Обновление: ln фактически создает копию, а не реальную ссылку

Answer 1

Вы используете SAMBA в качестве сервера? Затем найдите "расширения unix" в «smb.conf» и включите их.

https://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html#UNIXEXTENSIONS

С включенными "расширениями Unix" SAMBA поддерживает жесткие ссылки, информацию о владельце Unix и режим для файлов и каталогов (также известные как права доступа).

Однако этот параметр является глобальным. Поэтому включение расширений Unix влияет на все общие ресурсы (которые могут быть или не быть тем, что вы хотите).

Answer 2

Я недавно проверил это, используя Windows 10 Pro в качестве сервера. Моя система Linux работает под управлением CentOS 7, который на сегодняшний день поставляется с Samba 4.4.4. Hardlink работает хорошо, как и в локальной файловой системе.

тесты:

/mnt/f/tmp# mkdir a
/mnt/f/tmp# touch a/b
/mnt/f/tmp# cp -al a x
/mnt/f/tmp# stat a/b
  File: ‘a/b’
  Size: 0           Blocks: 0          IO Block: 16384  regular empty file
Device: 28h/40d Inode: 1688849861497214  Links: 2
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/   yanli)   Gid: ( 1000/   yanli)
Context: system_u:object_r:cifs_t:s0
Access: 2017-05-17 14:31:43.564755100 -0700
Modify: 2017-05-17 14:31:43.564755100 -0700
Change: 2017-05-17 14:31:46.571727600 -0700
 Birth: -
/mnt/f/tmp# stat x/b
  File: ‘x/b’
  Size: 0           Blocks: 0          IO Block: 16384  regular empty file
Device: 28h/40d Inode: 1688849861497214  Links: 2
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/   yanli)   Gid: ( 1000/   yanli)
Context: system_u:object_r:cifs_t:s0
Access: 2017-05-17 14:31:43.564755100 -0700
Modify: 2017-05-17 14:31:43.564755100 -0700
Change: 2017-05-17 14:31:46.571727600 -0700
 Birth: -
/mnt/f/tmp# echo something >a/b
/mnt/f/tmp# cat x/b
something
/mnt/f/tmp# mount | grep /mnt/f
//192.168.1.7/f on /mnt/f type cifs (rw,nosuid,nodev,noexec,relatime,vers=1.0,cache=strict,username=redacted,domain=REDACTED,uid=1000,forceuid,gid=1000,forcegid,addr=192.168.1.7,file_mode=0755,dir_mode=0755,nounix,serverino,mapposix,rsize=61440,wsize=65536,echo_interval=60,actimeo=1,user)

Как видите, файлы a/b и x/b имеют одинаковый номер Inode, что указывает на то, что они являются жесткими ссылками на один и тот же Inode. Изменение содержимого одного файла влияет и на другой файл.

ln тоже работает правильно.

Никакая специальная опция не использовалась для монтирования CIFS; каждый вариант был по умолчанию. Я не делал ничего особенного и на стороне Windows. Это просто установка Windows 10 Pro по умолчанию и простая общая папка.

Чего я пока не знаю, так это когда эта функция была добавлена в CIFS/Samba client/Windows. ОП сказал только "Общий ресурс Windows", поэтому не ясно, какую версию Windows/Samba он / она запускали. Я надеюсь, что мой ответ поможет тем, у кого проблемы с созданием жестких ссылок на смонтированном общем ресурсе CIFS, поддерживаемом сервером Windows; Вы можете решить эту проблему, обновившись до Windows 10 Pro и, по крайней мере, до Samba 4.4.4 (CentOS не известен как поставщик самого блестящего и новейшего кода).