O Cygwin não vê o compartilhamento do Windows como pasta - sem o atributo “d”?

1

Eu migrei essa pergunta do StackOverflow porque ela realmente estava fora do escopo das questões de programação que eles geralmente preferem, então espero encontrar um público mais adequado aqui ...

Instalei o Cygwin 1.7 em uma caixa do Windows Server 2008/64 para suportar uma configuração automatizada de transferência de arquivos. Enquanto a instalação básica geralmente está funcionando como esperado, tenho um problema curioso que deve ser resolvido.

Depois de entrar no servidor a partir de um prompt de comando do Windows via ssh, eu executo um "ls -l" contra o caminho UNC do servidor, por exemplo:

$ ls //servername

Isso retorna a lista de compartilhamentos nesse servidor; no entanto, alguns dos compartilhamentos são listados sem o conjunto de atributos "d" (diretório) - o Cygwin os vê apenas como arquivos regulares. Como resultado, as tentativas de criar um cd para o caminho de compartilhamento falham com erros "Não é um diretório". No entanto, ls contra esse nome de compartilhamento funciona.

Em alguns casos, o nome do compartilhamento e sua pasta subjacente contêm um espaço cada, de modo que foi meu primeiro suspeito, mas há outros compartilhamentos na mesma máquina sem espaços no nome do compartilhamento ou da pasta que exibem o mesmo comportamento.

Aqui está uma lista representativa, embora condensada, do comando ls, com nomes reais de compartilhamento / servidor / proprietário substituídos por ShareNameN, servername ou UserName, conforme apropriado. UserName é o da sessão do usuário ssh.

$ ls -l //servername
total 33636078380235
drwxrwxrwx+ 1 Administrators Domain Users                 0 Nov 26 10:35 ShareName1
-rw-r--r--  1 UserName       Domain Users 18193726281664696 Apr 22  2009 ShareName2
-rw-r--r--  1 UserName       Domain users 18189229448232975 Aug  4  1909 Share Name3

$ ls -l //servername/ShareName2
//servername/ShareName2

$ cd //servername/ShareName2
-bash: cd: //servername/ShareName2: Not a directory

$ ls //servername/"Share Name3"
//servername/Share Name3

$ cd //servername/"Share Name3"
-bash: cd: //servername/Share Name3: Not a directory

Eu tentei algumas outras permutações do nome do caminho UNC entre aspas, verifiquei as permissões no compartilhamento e na pasta subjacente, mas até agora, sem sorte. O usuário está autenticando por meio de uma senha real, não por meio de certificados.

Eu provavelmente estou perdendo algo óbvio, então se alguém pode ver o erro dos meus caminhos, eu ficaria muito grato!

EDIT: Acabei de observar um padrão interessante que pode ser um fator neste problema

Acabei de observar que esses compartilhamentos indicando uma data de criação diferente dos últimos meses - aqueles em que a hora do dia é listada em vez do ano - também não têm o atributo de diretório definido por meio do comando "ls". Todos os compartilhamentos que listam uma hora do dia têm o atributo de diretório definido e funcionam normalmente através do comando cd ...

    
por David W 08.01.2013 / 16:22

1 resposta

1

Eu determinei a causa deste problema, graças ao bom e velho ProcMon. Como as ações estavam sendo enumeradas, o ProcMon estava revelando um "ACCESS DENIED" na tentativa de abrir / consultar os compartilhamentos que estavam falhando, mas "SUCESSO" naqueles que funcionavam.

A conta usada para ssh no servidor de assunto não tinha permissões de leitura para os compartilhamentos em questão. A concessão das permissões de leitura da conta ao (s) compartilhamento (s) resolveu o comportamento do assunto.

    
por 08.01.2013 / 16:59