vi criando arquivos de permuta antes de criar um novo arquivo

Question

Este é um problema estranho. o arquivo de troca é criado para os novos arquivos. então, meu diretório está vazio, não existe nenhum arquivo e, quando eu vi test.txt recebo a mensagem do arquivo de troca. Parece que os arquivos vi create .swp como despejo de memória e mostram-me que restaurar a mensagem do arquivo.

    nfs setting:
    netapp-3240:/vol/vol0/test /testing nfs  rsize=8192,wsize=8192,timeo=14,intr     0 0

    [user@rh-test]cat /etc/redhat-release
    Red Hat Enterprise Linux Server release 5.9 (Tikanga)

    [user@rh-test]ls -la
    total 8
    drwx------ 2 root root 4096 Nov  8 15:35 .
    drwx------ 9 root root 4096 Nov  8 13:59 ..
    /testing 

    [user@rh-test]vi test.txt


    E325: ATTENTION
    Found a swap file by the name ".test.txt.swp"
              owned by: rahmed   dated: Fri Nov  8 15:30:06 2013
             [cannot be read]
    While opening file "test.txt"
                 dated: Fri Nov  8 15:29:59 2013

    (1) Another program may be editing the same file.
        If this is the case, be careful not to end up with two
        different instances of the same file when making changes.
        Quit, or continue with caution.

    (2) An edit session for this file crashed.
        If this is the case, use ":recover" or "vim -r test.txt"
        to recover the changes (see ":help recovery").
        If you did this already, delete the swap file ".test.txt.swp"
        to avoid this message.

    Swap file ".test.txt.swp" already exists!
    [O]pen Read-Only, (E)dit anyway, (R)ecover, (D)elete it, (Q)uit, (A)bort:

    [user@rh-test]ls -la
    total 8
    drwx------ 2 root   root          4096 Nov  8 15:39 .
    drwx------ 9 root   root          4096 Nov  8 13:59 ..
    -rwx------ 1 user   sysadmins    0 Nov  8 15:39 .test.txt.swo
    -rwx------ 1 user   sysadmins    0 Nov  8 15:39 .test.txt.swp

é claro, se eu criar um arquivo por eco, então nenhum arquivo de troca.

    [user@rh-test]echo "this is test file" > test.txt

    /testing
    [user@rh-test]ls -la
    total 8
    drwx------ 2 root   root          4096 Nov  8 15:29 .
    drwx------ 9 root   root          4096 Nov  8 13:59 ..
    -rwx------ 1 user   sysadmins   18 Nov  8 15:29 test.txt

A saída de :set dir é directory=.,~/tmp,/var/tmp,/tmp

Por favor, note que isto está acontecendo apenas com esta montagem nfs /test . o outro local e o nfs são montados no mesmo sistema sem este problema.

opções de montagem:

netapp-3240:/vol/vol0/test on /testing type nfs (rw,rsize=8192,wsize=8192,timeo=14,intr,addr=10.200.23.22)

Depois de mudar para nfsvers = 2, ele está começando a funcionar

nfsvers = 2 ou nfsvers = 3 - Especifica qual versão do protocolo NFS deve ser usada. Isso é útil para hosts que executam vários servidores NFS. Se nenhuma versão for especificada, o NFS utilizará a versão suportada mais alta pelo kernel e pelo comando mount. Esta opção não é suportada com o NFSv4 e não deve ser usada.

netapp-3240-2:/vol/vol1/testing on /test type nfs (rw,rsize=16384,wsize=16384,intr,nfsvers=2,addr=10.200.23.22)

**

Resolvido:

Esse problema estava relacionado à opção NetApp não definida corretamente. Para resolver isso, tivemos que definir essa opção nas opções da NetApp cifs.ntfs_ignore_unix_security_ops em 'on NetApp. **

    

Answer 1

Tópico de e-mail

Eu encontrei este tópico de 2008, parece datado, mas soa exatamente como o seu problema. Parece ser algo com a NetApp especificamente. Observei que, na sua saída, o servidor tinha o nome netapp-3240 , que eu supus era um appliance da NetApp.

O tópico é intitulado: comportamento estranho, Linux e NFS no NTFS qtree . Especificamente, há menção dos mesmos sintomas que você está experimentando.

Sinopse do problema

trecho

I'm seeing some strange behaviour with a FAS3040 filer I have on evaluation at the moment. I have an NTFS-style qtree exported by NFS and CIFS. Debian Linux clients see odd behaviour relating to open() and stat64() system calls. This strace output from "vim" captures it in a nutshell:

   uname({sys="Linux", node="acheron", ...}) = 0 
    stat64("ffff", 0xbfb4d030) = -1 ENOENT (No such file or directory) 
    stat64("ffff", 0xbfb4d0b0) = -1 ENOENT (No such file or directory) 
    access("ffff", W_OK) = -1 ENOENT (No such file or directory) 
    open("ffff", O_RDONLY) = -1 ENOENT (No such file or directory) 
    readlink("ffff", 0xbfb4c7cc, 1023) = -1 ENOENT (No such file or directory) 
    open(".ffff.swp", O_RDONLY) = -1 ENOENT (No such file or directory) 
    open(".ffff.swp", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied) 
    stat64(".ffff.swp", {st_mode=S_IFREG|0777, st_size=0, ...}) = 0 

Note that the open(O_RDWR...) call fails with EACCES; but the following stat64() call succeeds. The file ffff.swp was created on disk despite the reported failure of the open() call.

This behaviour is seen using "vim" to edit files, and causes an error message about the swap file being present (due to the swap file being created even though the open() return value implies it was not).

Trying the same "vim" command on a Tru64 NFS client, correct behaviour is seen: the open(O_RDWR...) succeeds and a filehandle is returned.

nfsver = 2

Houve essa sugestão que corrigiu o problema. Você pode tentar por nenhum outro motivo além de confirmar que está enfrentando o mesmo problema que este segmento está abordando.

trecho

But after your email I tried vers=2 and the problem goes away (with both TCP and UDP) which is interesting indeed. Although with the crazy size files and filesystems around here, NFSv3 is very desirable.

Fazendo algo assim em suas exportações:

rw,intr,tcp,nfsvers=2,rsize=16384,wsize=16384,addr=192.168.1.1

cifs.ntfs_ignore _... opção

Havia mais uma coisa para testar no tópico:

Setting the option cifs.ntfs_ignore_unix_security_ops to on on the filer might work.

O que mais?

Além dessas coisas, havia várias outras coisas para tentar que não consegui confirmar, pois não tenho acesso a um arquivador NetApp no qual tentar. Havia algumas URLs no site da NetApp que você poderia explorar, mas eu não tinha acesso para confirmar qualquer uma dessas coisas.

De qualquer forma, eu sugiro que você passe por este tópico, já que ele parece ser o principal candidato para o seu estranho vim dizendo que ele tem um arquivo .swp quando na verdade não.