cp -a falha ao copiar links simbólicos no virtfs

2

Problema:

Tentando copiar todo o conteúdo de um diretório para outro, o que inclui arquivos / diretórios ocultos e links simbólicos.

Isso é relativamente simples. cp -a ${src} ${dst}

Funciona como esperado na minha VM local, mas não funciona corretamente no meu VPS (hostgator). Ele não copia os links simbólicos se o destino do link vier mais tarde na listagem de diretórios.

Considerando que os alvos do link original funcionam, são locais do dispositivo e estou copiando no mesmo dispositivo, qual é a melhor maneira de garantir que toda a estrutura de diretórios seja copiada exatamente?

Demorei um bom tempo, mas descobri que tudo o que preciso fazer é executar o comando copy duas vezes e a segunda passagem adiciona os links ausentes. Existe uma maneira melhor do que isso?

Trabalhando, mas com solução Hack-ish:

src=".default/.";
dst="tld.domain/";
cp -a ${src} ${dst};
cp -a ${src} ${dst};

Eu não precisaria dobrar o comando para garantir que tudo fosse copiado corretamente.

Eu tentei tar também, mesmo problema. Eu não tentei o rsync mas ambos parecem uma solução exagerada para algo que deveria ser uma coisa bem trivial.

Cenário:

Para uma perspectiva adicional, caso seja importante ou não seja claro.

Eu criei uma estrutura de diretório de modelo para domínios de website. Depois de criar um novo subdomínio no meu host, copio o modelo para a raiz do documento do subdomínio.

Esta é minha estrutura de diretórios de subdomínio e modelo (.default /):

sites/
    .default/
        .htaccess
        .www -> production/
        production/
    tld.domain.x/
    tld.domain.y/
    tld.domain.z/

Então, eu crio um novo subdomínio e, em seguida, preencho a raiz do documento com o conteúdo do diretório do modelo. O problema aqui é que .www/ é um link simbólico para production/ mas cp et al cria tudo em ordem de classificação para tentar criar .www/ antes de criar production/ e consequentemente falhar.

Meu host da web é um VPS do HostGator que executa o CentOS6

Eu posso detalhar o problema com alguma restrição na criação de links simbólicos. Meu palpite é que o VPS não permite links simbólicos para fontes externas que normalmente se comportariam da mesma forma que um destino de link inválido. Fonte desconhecida do IE.

Onde não existem nomes, chamando meu VPS:

ln -s foo bar

Saídas:

ln: creating symbolic link 'bar': Permission denied

Se eu criar foo / first e depois link, funcionará como esperado.

df -T . mostra que o tipo de sistema de arquivos é virtfs .

    
por Fuzzy Logic 07.03.2015 / 02:55

1 resposta

0

Normalmente, um link simbólico é inerte: ele pode armazenar qualquer seqüência de bytes (exceto bytes nulos e somente até um determinado comprimento). Ao criar um link simbólico, é irrelevante se o conteúdo aponta para um arquivo existente. É somente ao acessar o link simbólico que a existência do alvo é importante. Então, o que você está vendo no seu VPS é anormal (e incomum, para iniciar).

O Virtfs é um sistema de arquivos projetado para máquinas virtuais KVM / QEMU onde o convidado e o host estão executando o Linux. Este sistema de arquivos apresenta uma parte do sistema de arquivos do host no guest. Ele permite compartilhar arquivos entre o convidado e o host de maneira fácil e rápida (mais rápido que um sistema de arquivos de rede). É útil em um VPS, por exemplo, em que todos os convidados estão executando o mesmo sistema operacional, portanto, os arquivos do sistema operacional são compartilhados (somente leitura, espera-se) entre o host e todos os convidados. Ele também pode ser usado para arquivos específicos de convidados (que não são compartilhados com nenhum outro convidado).

O Virtfs oferece dois modos de armazenamento: mapeado e passthrough . O modo Passthrough, como o nome sugere, simplesmente passa os comandos de manipulação de arquivos do convidado para o host; por exemplo, criar um symlink no guest cria um symlink no host. O modo mapeado usa atributos estendidos no host para armazenar metadados de arquivos e torna todos os arquivos de propriedade do usuário que está executando o QEMU. O modo mapeado é apropriado para armazenar arquivos por convidado, porque eles pertencem ao único usuário que está executando o QEMU, não importando o usuário que os possui no guest. Seu site é presumivelmente armazenado em uma instância do virtfs no modo mapeado.

No modo mapeado, os links simbólicos são armazenados como um arquivo regular, com um atributo estendido indicando que eles são um link simbólico. Isso, por si só, não explica o seu problema. No entanto, abre uma janela de oportunidade para algo dar errado. Parece que algo está verificando a existência de alvos de links simbólicos e negando a criação deles se o destino não existir.

Eu não tenho experiência com virtfs, então não posso dizer se isso é devido a alguma opção de configuração. Eu encontrei um problema semelhante ao seu . O usuário afetado também estava em um VPS e também recebeu erros de “permissão negada” ao tentar criar um link simbólico pendente. Sua conclusão foi

FYI, the problem is not RedHat 4.4 - the ln -s command is broken on purpose by the system provider to prevent users from installing things like RVM.

Você pode entrar em contato com seu provedor de VPS para solicitar uma explicação e, com sorte, uma correção.

Se você não conseguir obter uma correção, uma solução alternativa seria primeiro copiar diretórios e arquivos regulares e, em seguida, copiar os links simbólicos. Eu não acho que nenhum dos programas de cópia usuais (GNU cp , rsync, cpio, tar, pax) tenha qualquer forma de copiar tudo, mas deixar apenas os links simbólicos. Uma solução simples é executar a cópia duas vezes (com rsync, para que os arquivos já copiados não sejam copiados novamente), ignorando os erros na primeira rodada:

rsync -a source/ destination/ 2>/dev/null
rsync -a source/ destination/
    
por 08.03.2015 / 01:53