Liberando arquivos bloqueados pelo recurso Pastas Compartilhadas


16

Faço muito uso do recurso Pastas Compartilhadas do VMWare Workstation: você define uma pasta na máquina host como compartilhada para o SO convidado e pode acessá-la no convidado, da mesma maneira que um compartilhamento SMB (somente leitura ou leitura / gravação) .

O que me incomoda é que, depois de copiar alguns arquivos de hots para convidados, a Estação de Trabalho impede que esses arquivos sejam gravados, mesmo que o compartilhamento seja definido como somente leitura .

Isso é especialmente irritante no cenário geralmente quando estou tentando depurar / usar um script no convidado enquanto ainda o edito no host.

Até agora, as únicas maneiras pelas quais sei fazer a Workstation liberar esses arquivos são:

  • suspender a máquina convidada: é uma terrível pseudo-solução alternativa. É lento (especialmente com maior quantidade de RAM de convidado) e às vezes a interrupção pode não ser bem-vinda
  • copiar quantidade de alguns outros arquivos aleatórios, esperando que a Estação de Trabalho tenha um limite interno para a quantidade de arquivos que ele bloquearia: tal hack que só seria útil regularmente se soubéssemos a quantidade e o tamanho que era pequeno

Então, quais são algumas boas maneiras de fazer com que a Workstation libere esses arquivos?

Ou, alternativamente, como evitar travá-los em primeiro lugar?

Edit: Eu não deixei algumas coisas claras:

  • Eu sei que é a estação de trabalho (vmware-vmx.exe) que está bloqueando esses arquivos (provavelmente devido a algum buffer interno)

  • Não quero liberar os arquivos à força. Eu tentei isso, mas liberá-los à força torna a máquina instável, o que não posso pagar

Aparentemente, isso é causado por um bug na estação de trabalho.


Por que não apenas configurar o compartilhamento real de arquivos de rede?
Jftuga 3/12/12

@ jftuga Eu prefiro o SF e tenho tudo isso por várias razões, algumas delas: é muito mais rápida; não precisa de rede. Veja este post
Alois Mahdal

O problema continua a existir na Estação de Trabalho 11 e nas pastas compartilhadas entre dois convidados win7. O arquivo criado por um convidado é bloqueado para todos os sistemas, incluindo o host, se outro convidado usar o arquivo. A única coisa que funciona para mim é ir ao convidado que criou o arquivo, desabilitar a pasta compartilhada e reativar. E as etapas são dolorosas porque não há personalização da barra de ferramentas para acessar rapidamente a página de configurações da pasta compartilhada. Ou existe?
User173399 28/05

Observe que esse problema ainda persiste na estação de trabalho 12.5. No meu caso, a VM acabou de ler um arquivo para anexar a um email e, mesmo depois que o programa de email foi fechado, a Estação de Trabalho mantinha uma trava de arquivo aberta que o Unlocker não podia ver ou remover.
Mark Booth

Respostas:


8

Parece ser um bug no VMWare, portanto, não há necessidade de verificar um software antiviral de terceiros ou usar desbloqueadores - todos estes últimos interrompem o funcionamento normal da própria VMWare Workstation.

Vários threads no fórum VMWare solucionam o mesmo problema. Por exemplo:

A única solução que funciona é mencionada nas mensagens de Loren Pechtel , portanto todos os créditos devem ser atribuídos a ela: você deve acessar ("tocar") o arquivo bloqueado no sistema convidado.

Por exemplo, abro e fecho as propriedades do arquivo bloqueado no Windows Explorer no convidado. Isso é suficiente para eliminar a trava no host.


3

Encontrei o mesmo problema usando um script para copiar arquivos de uma pasta de host compartilhada para o meu cliente. Terminou com arquivos bloqueados no host. A maneira mais fácil de contornar isso é fazer como os outros postaram anteriormente, acessar o arquivo host do cliente usando um comando.

Para mim, usei "attrib -r HOST_FILE" no meu script depois de copiar o arquivo host. Desde que montei minha pasta compartilhada como somente leitura, isso não fez mais do que limpar o bloqueio.


2

Algumas ideias :

  1. Verifique se algum programa (como um antivírus) está lendo os arquivos, tanto no host quanto no convidado.
    Eu normalmente uso o Unlocker ou o Process Explorer para isso.
  2. Verifique se os arquivos não estão apenas copiando muito lentamente.
    Pode ser que o convidado tenha um driver de rede problemático.
  3. Tente desativar todos os firewalls, antivírus ou outros produtos de segurança.
  4. Estou mais do que convencido de que existe um bug sério na implementação do VMware de pastas compartilhadas, onde host e convidado podem ficar totalmente confusos. Normalmente, evito pastas compartilhadas, porque é impossível adivinhar com antecedência se elas funcionarão de maneira confiável em qualquer nova configuração, enquanto os compartilhamentos de rede ou FTP sempre funcionam.

Obrigado por sugestões. 1. Sim, o vmware-vmx.exe geralmente está bloqueando esses arquivos, mas não consigo usar a força para desbloquear - tentei, mas tornou a Estação de Trabalho instável. 2. Verificado - não é o caso. Isso normalmente acontece comigo com um pequeno arquivo que eu vejo completo. 3. Tentei, não ajudou. 4. Sim, isso é um bug, então, na verdade, estou procurando uma solução alternativa.
Alois Mahdal

E, quanto a evitar o SF: para mim, por quase dois anos de testes diários, provou que, de todas as soluções, o SF é o mais confiável (e mais rápido). A razão mais significativa para isso é que eles realmente não dependem da rede: você pode ter firewalls restritivos, driver quebrado ou zero NICs no convidado e ainda transferir arquivos como desejar via SF.
Alois Mahdal

Sem problemas em 2 anos? Que sorte! A maior parte do meu SF nunca funcionou ou foi lenta demais para ser utilizável, e o mesmo que você está vendo agora, sem motivo óbvio. A única sugestão que me resta é usar a versão mais recente do VMware e das ferramentas do VMware (reinstalar mesmo se estiver atualizado, apenas por precaução), excluir e recriar o SF. Às vezes isso ajuda. Mas, se isso não acontecer, o único próximo passo que posso ver é entrar em contato com o suporte da VMware.
harrymc

Ironia: logo após meu comentário sobre a confiabilidade do SF, atualizei para a Estação de Trabalho 8 e comecei a ter problemas: tudo terminaria se \\vmware-host\Shared Folders\folder\subfoldernão \\vmware-host\Shared Folders\folderfosse aberto pelo menos uma vez desde a inicialização. Eu não estou trabalhando nessa empresa (e provavelmente não vai ver o Windows por um longo tempo, yay), embora ...
Alois Mahdal

Quando isso aconteceu comigo, o Workstation 12.5 Unlocker não pôde ver nem remover nenhum bloqueio de arquivo. Eu nunca vi esse problema com Workstation 7.
Mark Booth

2
  1. você pode tentar usar o Unlocker Software ( clique para baixar o unlocker )

    Instale o Unlocker, desativando a opção para extensões do Explorer e outros itens indesejados

  2. abra o CMD e navegue até C: \ Arquivos de Programas \ Unlocker.

  3. execute o Unlocker.exe "o caminho para a pasta bloqueada", no CMD.

  4. uma pop-up confirmando a liberação do bloqueio, depois clique em desbloquear para desbloquear o arquivo.

  5. Concluir, o arquivo foi desbloqueado,

Desculpe, eu gostaria de evitar o uso de software " suportado por anúncios " (soa quase como um ad-ware). (Eu já tenho Process Explorer para essas coisas.)
Alois Mahdal

@AloisMahdal Pode estar se referindo apenas ao pacote de barras de ferramentas com o instalador (que você deve desmarcar ao instalar). De qualquer forma, eu pessoalmente prefiro o site oficial / desenvolvedor para downloads de software, não sites como o Softpedia. Obviamente, o Process Explorer funciona tão bem e você já declarou que o fechamento forçado dessas alças causa instabilidade.
Bob

0

O desbloqueador Emco (freeware - sem anúncios) funciona bem. Depois de transferir os arquivos, basta enviar a pasta (para onde você copiou ou moveu os arquivos no host) para o desbloqueador de arquivos Emco. Coloquei um atalho na minha pasta "enviar para". Rápido e eficaz.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.