[CPMD-list] Upon compilation of cpmd2cube...

[kohsj at ihpc.a-star.edu.sg]

Thanks Dr. Axel.  I should've mentioned that the previous versions of "Makefile" that you attached did not produce the ".nfsXXXXX" files, only the latest one did.

Any clue as to why this "Makefile" gave those files?

Cheers,
Adrian.



----- Original Message -----
From: Axel Kohlmeyer <axel.kohlmeyer at theochem.ruhr-uni-bochum.de>
Date: Thursday, May 27, 2004 4:22 pm
Subject: Re: [CPMD-list] Upon compilation of cpmd2cube...

 
 On Thu, 27 May 2004 kohsj at ihpc.a-star.edu.sg wrote:
 
 AK> Dear Dr. Axel,
 AK> 
 
 AK> Is there any way that one can remove the .nfsXXXXX files, and
 AK> subsequently, the "cpmd2cube-v0.1.1" folder?
 
 the explanation should have made it clear, that you simply
 have to terminate _all_ processes accessing files in that directory,
 including editors, file viewers, file managers, directory browsers etc.
 
 axel.
 
 AK> 
 AK> Thanks again!
 AK> 
 AK> 
 AK> 
 AK> AK> My IT man suggested that it could probably be:
 AK>  AK> 
 AK>  AK> 
 AK>  AK> "Since you are the one who create the folder, you shall 
 have the 
 AK>  right to
 AK>  AK> remove anything in the folder. However, you claim that you 
 AK>  delete the
 AK>  AK> file and it come back again. This is mostly likely due to 
 your 
 AK>  program.AK> You may have write a program and this program may 
 need 
 AK>  to write
 AK>  AK> something in this folder everytime it is running and 
 therefore 
 AK>  the file
 AK>  AK> come back after you delete it. I just make a guess and I do 
 not 
 AK>  have any
 AK>  AK> evidence to support my point. Hope that clear your doubt."
 AK>  
 AK>  well, this is close to the explanation. the reason for the 
 .nfsXXXXX 
 AK>  filesis 'feature' of NFS in order to emulate posix style file 
 access 
 AK>  semantics.to explain: if you delete a file on a posix/unix 
 machine, 
 AK>  the file is
 AK>  initially only removed from the directory listing but not 
 deleted if 
 AK>  thereis still a process, that has an open file descriptor 
 pointing 
 AK>  to that
 AK>  file. only if the last process accessing the file has ended, 
 that 
 AK>  file is
 AK>  really deleted. this is btw a very convenient way of creating 
 AK>  'invisible'scratch files, that get automatically deleted, when 
 the 
 AK>  process terminates
 AK>  or dies (you open(2)/fopen(3) a file with a unique name for 
 writing 
 AK>  and 
 AK>  immediately unlink(2) it). back to the .nfsXXXX file: the NFS 
 AK>  filesystem,however is basically 'stateless', i.e. the 
 connection to 
 AK>  the NFS server 
 AK>  can be interrupted any time and later reconnected (in some 
 cases it 
 AK>  can 
 AK>  even survive an intermediate reboot with replacing the hardware 
 and 
 AK>  resizing the filesystem). so to implement the 'file-stays-even-
 if-
 AK>  deleted'semantics, the nfs server daemon acts as a proxy for 
 the 
 AK>  processes 
 AK>  accessing the file, but to make this work even in case of a 
 reboot, the
 AK>  .nfsXXXX files are created. the XXXXX is an hash, that allows 
 the 
 AK>  serverto detect the process needing to access the 'file with no 
 name'.AK>  most frequently this happens if you open a file in an 
 editor, that
 AK>  keeps an open file descriptor to the file it opens (or to the 
 AK>  associated backup/undo file).
 AK>  
 AK>  
 AK>  
 AK>  axel.
 AK> 
 
 -- 
 
 
 =======================================================================
 Dr. Axel Kohlmeyer                        e-mail: axel.kohlmeyer at rub.de
 Lehrstuhl fuer Theoretische Chemie          Phone: ++49 (0)234/32-26673
 Ruhr-Universitaet Bochum - NC 03/53         Fax:   ++49 (0)234/32-14045
 D-44780 Bochum  http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/
 =======================================================================
 
 
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kohsj.vcf
Type: text/x-vcard
Size: 255 bytes
Desc: Card for <kohsj at ihpc.a-star.edu.sg>
Url : http://cpmd.org/pipermail/cpmd-list/attachments/20040527/0c14361b/attachment.bin