Solução
Os arquivos e diretórios no diretório .linktorootdir são copiados do diretório raiz. Você pode simplesmente excluí-los usando, por exemplo, rm -rf /volume1/usbcopy/USBCopy_1303012145/.linktohomedir .
A explicação está abaixo.
Hardlinks de diretórios
Hardlinks para diretórios são teoricamente possíveis, mas por causa de vários motivos eles estão desabilitados em muitos sistemas, incluindo o Linux. Isso também significa que você não poderá remover um link físico para o diretório, pois o unlink() syscall não permitirá isso.
Demonstração
root@x:~/testdir# ln -F dir1 dir1link
ln: failed to create hard link 'dir1link' => 'dir1': Operation not permitted
root@x:~/testdir# unlink dir1
unlink: cannot unlink 'dir1': Is a directory
A negação mostrada é programada no kernel do Linux ( fs/namei.c ) . Aqui estão os resultados de syscalls:
linkat(AT_FDCWD, "dir1", AT_FDCWD, "dir1link", 0) = -1 EPERM (Operation not permitted)
unlink("dir1") = -1 EISDIR (Is a directory)
Reconhecendo os dois tipos de links
-
softlink -
ls -lmostralcomo o primeiro caractere do campo de tipo / permissão.statoutput mostrasymbolic link. -
hardlink - Os hardlinks são indistinguíveis entre si. Tanto o arquivo original quanto o hardlink recém-criado são exatamente iguais, exceto o caminho / nome do arquivo. Hardlinks não podem apontar de um sistema de arquivos para outro.
ls -imostra o mesmo número de inode para todos os arquivos vinculados aos mesmos dados (representados por inode). A segunda coluna dels -lmostra o número de hardlinks para o inode.
user1@x:~/testdir$ ls -li
total 12
6865008 drwxrwxr-x 2 user1 user1 4096 Jul 30 00:50 dir1
6822146 lrwxrwxrwx 1 user1 user1 4 Jul 30 01:44 dir1symlink -> dir1
6822155 -rw-rw-r-- 2 user1 user1 64 Jul 30 01:44 file1
6822155 -rw-rw-r-- 2 user1 user1 64 Jul 30 01:44 file1hardlink
user1@x:~/testdir$ stat * | grep -E '((File)|(Size)|(Device)):'
File: 'dir1'
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 807h/2055d Inode: 6865008 Links: 2
File: 'dir1symlink' -> 'dir1'
Size: 4 Blocks: 0 IO Block: 4096 symbolic link
Device: 807h/2055d Inode: 6822146 Links: 1
File: 'file1'
Size: 64 Blocks: 8 IO Block: 4096 regular file
Device: 807h/2055d Inode: 6822155 Links: 2
File: 'file1hardlink'
Size: 64 Blocks: 8 IO Block: 4096 regular file
Device: 807h/2055d Inode: 6822155 Links: 2
Origem de .linktorootdir
No diretório .dfmdesk DFM cria alguns links durante a primeira inicialização. Esses links serão mostrados como ícones na área de trabalho. Entre os links, haverá dois links para diretórios: .linktorootdir como link simbólico para o diretório raiz do sistema DFM está em execução e também .linktohomedir . Veja a documentação do DFM e o Fonte DFM .
No seu caso, os diretórios / e /volume1/usbcopy/USBCopy_1303012145/.linktohomedir estão em sistemas de arquivos diferentes ( /dev/root e /dev/vg1000/lv ), portanto, eles não podem ser hardlinks para o mesmo inode. (Hardlinks podem apontar apenas no escopo de um único sistema de arquivos.)
Podemos adivinhar como surgiu o problema que você descreve. Muito provavelmente, o backup para NTFS foi capaz de manter o link simbólico como NTFS tem esse recurso. Mais tarde, quando você copiou o backup da unidade USB, a ferramenta de cópia não manipulou links simbólicos conforme o esperado. Em vez de copiar apenas o próprio link simbólico, a ferramenta seguia os links simbólicos na unidade de origem e copiava o conteúdo deles (diretório raiz no caso de .linktorootdir ). O problema semelhante é descrito também no fórum Synology: USBCopy cought em loop infinito ao copiar o HDD .
A solução é descrita no começo.