Windows 7 mklink - atributos do link físico (esperado!) + conteúdo não afeta o arquivo vinculado

Question

Eu criei um link físico apontando para um arquivo no meu diretório dropbox - o link foi criado dentro de uma pasta onde este arquivo precisa estar para ser acessado pelos programas que eu uso para editá-lo -

mklink /h path_to_hard_link C:\dropbox\git\repo\existing_file

Comecei a trabalhar com o link físico. Em algum momento eu percebi que as alterações não se propagam para o arquivo em repo \ - filesize, data de modificação, nada - nem mesmo o conteúdo.

O que estou fazendo de errado?

EDIT: é possível ser dependente do programa? Quero dizer, o editor que eu uso para esses arquivos de fato os edita - mas edita apenas o hard link . O arquivo vinculado não foi modificado. Além disso, este editor não parece ser capaz de seguir links simbólicos

EDIT2: de acordo com o artigo linkado pelo surfasb:

Because a hard link is a directory entry for a file, an application can modify a file by using any of its hard links. Applications that use any other hard link can detect the changes.

O que significa que o arquivo original deve conter as modificações quando aberto diretamente com um editor apropriado - não apenas através de seu link físico - certo?

However, directory entries for hard links are updated only when a user accesses a file by using the hard link. For example, if a user opens and modifies a file by using its hard link, and the size of the original file changes, the hard link that is used to access the file also shows the new size.

Se eu entendi este exemplar deplorável do inglês corretamente, isso significa que eu posso ter 69 hard links (até 1023, na verdade) para o mesmo arquivo mostrando tamanhos diferentes para o mesmo arquivo ?!

EDIT 3: bem de acordo com o surfasb eu entendo isso corretamente - uma limitação do sistema de arquivos. De qualquer forma - coisa estranha - isso nem sempre é o caso - às vezes a mudança nos atributos é imediatamente visível de volta ao arquivo original - quando há mudança - minha preocupação real agora é que pelo menos um programa que estou usando não parece editar o arquivo vinculado, mas apenas o link físico. Possível ? dir /a não revela muito sobre hard links - alguma maneira de vê-los?

    

Answer 1

Acho que a resposta é (citada de algum cara útil):

What you have to consider is the way an application/program works on a file.

Some edit the file directly, and they should work perfectly fine with hardlinks. Although I didn't knew the "fileinfo difference" problem until now ...

Other applications copy the file and then delete the old one when they save their edited version. This programs obviously break the hard link with that hidden copy operation. What they save is no longer the file they had opened. When they then delete the old version, they remove this single hardlink from the directory. Other hardlinks remain, and so you get two files in the end.

Então, sim - os hardlinks podem e irão quebrar - o que limita sua utilidade - mal pensados.

corrija-me se estiver errado

    

Answer 2

Você ativou a configuração Última hora acessada? Ele está desativado por padrão, começando com o Vista ++, devido a razões de desempenho.

Eu vejo muito essa pergunta. Eu sempre digo às pessoas para baterem na technet e lerem as documentações sobre o NTFS.

link

Observe que o NTFS não imediatamente grava o LAT no disco. Em geral, ele espera a diferença ser uma hora ou apenas aceita as alterações gravadas nesse arquivo. Consultas com base em arquivo, no entanto, estará correto.

Esta não é uma ferramenta de auditoria. Haverá casos em que o NTFS não atualizará o LAT ao custo do desempenho. Se você estiver procurando por uma ferramenta de auditoria, sugiro que ative a auditoria de segurança local. Ele registrará o acesso all a um arquivo, diferentemente do LAT. Por exemplo, existem inúmeras chamadas de API que você pode usar que não afetarão o LAT.

Editar Resposta para comentar abaixo.

Will be reading this - but a) I was actually most concerned with the LMT and b) not even the size and contents of the file did change - Can it be program dependent ?? It most definitely shouldn't. I am starting to appreciate Unix and the i nodes here - EDIT : the size and times are not supposed to propagate (need confirmation on this) but the contents should

O artigo aborda especificamente seus problemas exatos. Vou citar o artigo. Enfatizar foi adicionado por mim.

O conteúdo do arquivo deve ter mudado ou você não fez isso corretamente.

Because a hard link is a directory entry for a file, an application can modify a file by using any of its hard links. Applications that use any other hard link can detect the changes. However, directory entries for hard links are updated only when a user accesses a file by using the hard link. For example, if a user opens and modifies a file by using its hard link, and the size of the original file changes, the hard link that is used to access the file also shows the new size.

Portanto, embora o arquivo em si tenha sido alterado, as entradas de diretório correspondentes não serão atualizadas, a menos que estejam sendo acessadas. Portanto, se você tiver um arquivo de texto aberto por meio de dois hardlinks correspondentes, as duas entradas do diretório serão alteradas. Agora, se você tiver apenas o arquivo aberto através do hardlink A, o hardlink B não será atualizado. O arquivo terá as alterações que você fez. Mas, novamente, hardlinks são entradas de diretório e o NTFS não atualiza a entrada de diretório se você não estiver usando. Seria um desperdício de E / S.

Agora, presumo que você esteja vendo tudo isso através do Explorer. O Explorer lista informações muito parecido com a digitação dir na linha cmd. Uma listagem de diretórios é apenas isso, uma listagem. Ler uma lista de diretórios não acessa o arquivo, no entanto, o que é importante. Caso contrário, obter uma listagem de diretório fará com que todo o último horário de acesso do arquivo seja alterado !! Portanto, você obterá informações desatualizadas se houver um link físico. Você pode forçar o Explorer a acessar o arquivo clicando com o botão direito do mouse e, por exemplo, verifique a guia detalhes. Ou apenas abrindo o arquivo.

edit3

not entirely getting the difference - when hitting ^c then ^v on a foo.txt (so windows creates a file like foo - Copy.txt and places it in the current directory) - is this copying in which sense ?

Isso foi complicado porque não tenho idéia de como o Explorer lida com a cópia de um arquivo existente em seu diretório atual. Então eu tive que testar isso. Parece que o Explorer copia o destino do arquivo de origem, se o arquivo de origem é um link físico ou um link simbólico.

O Explorer não tem controle e suporte muito granulares para links simbólicos e hardlinks. Agora, é possível copiar o próprio link, se você usar "mklink /h Foo1.txt Foo.txt" . Isso cria um novo hardlink chamado Foo1.txt . Você não pode fazê-lo no Explorer embora. Eu sugiro que você obtenha o Link Shell Extension. Ele se sobrepõe a links com ícones de seta de atalho personalizados, enumera os alvos e permite a criação explícita de links simbólicos e hardlinks.

Edit4

well according to surfasb I do understand this correctly - a limitation of the filesystem - I now appreciate the inode concept. Anyway - strange thing - this is not always the case - sometimes the change in the attributes is immediately visible back to the original file - when there is change - my real concern now is that at least one program I am using does not seem to edit the file linked but only the hard link. Possible ? dir /a does not reveal much about hard links - any way to see them

Não me lembro de ver essa parte da sua pergunta. Estou curioso sobre o programa que não edita o arquivo vinculado. Qual programa é esse?

Um dir /a não atualizará as entradas do diretório. Isso ocorre por design, porque seria bastante intensivo de desempenho.