[rdiff-backup-users] Fwd: NFS "OSError: [Errno 39] reason and workaround

[Troels Arvin]

Bernd Schubert has tried subscribing to this list, but without luck. - So
I forward the below quoted mail for him. Looks to me like valuable
information on the "Errno 30" problem which some people experience on
certain file systems (NFS, XFS, perhaps others).

/Troels

==================== mail-quote: ====================

From:    Bernd Schubert <address@hidden>
To:      address@hidden
Subject: list trouble and NFS "OSError: [Errno 39] reason and workaround
Date:    Sat, 30 Oct 2004 23:25:24 +0200


Hello,

Well, I'm pretty new to rdiff-backup as I first installed and used it last 
Monday. After rdiff-backup saved all files properly to a nfs-directory, it 
faild with this "OSError [Errno 39]" message on the second run. After some 
thinking about it, I guessed that its probably the locking daemon that causes 
the trouble and remounted that directory without file locking, which 
immediately made the problem going away. Since two days its working fine now, 
thats not much time to be really sure, but maybe others on this list could 
confirm it? You just need to give the 'nolock" option on mounting the 
nfs-volume.

So whats the reason for the problem? Well, just an example, you have a 
file /somewhere/somefile and open it or somefile is an executable and you 
execute it. For some reason you decide to delete it (on the same machine 
where its open or executed). The lock daemon will detect that this file is 
still needed and will move your file to /somewhere/.nfs{some_random_letters} 
and furthermore change the filedescriptors for the "deleted" file to 
this .nfs.... file. Finally when the executable has finished or the open file 
is closed, this .nfs.... file will be really deleted. (Disclaimer: I only 
have some slight deeper knowledge about the nfs server and protocol itself, 
but I do nothing know about the locking insights, a real expert might correct 
me here).
Somehow I think that rdiff-backup opens a file in this directory, deletes this 
file, deletes the directory and first then decides to close this file (if it 
closes it at all). 
Everyone so far could follow me?  As I have absolutely no knowledge about 
python, I hope someone on the list could help me finding the open/close code 
of rdiff-backup. However, I can definitely state that I won't have one more 
second time to care about rdiff-backup until November 15th.

Cheers,
 Bernd