Re: [Duplicity-talk] restore OSError: [Errno 84]

[edgar . soldin]

On 20.04.2012 22:08, Nate Eldredge wrote:
> 
> Otherwise, for a temporary workaround, it shouldn't be too hard to find the 
> place in the duplicity code where it opens the file, and either make it 
> continue when an error occurs, or else hack it to modify the filename somehow 
> to make it legal.  If you were seriously considering making an LVM volume out 
> of loopback devices then this should be a hack of much lower magnitude and 
> well within your capabilities :)

the stack tells us where it happens.

path.py:setdata() tries to update the stat data (no clue what for on a restore? 
in case the local file has different attributes than the backup'd?)
@Ken: any idea why?
there is already a routine that catches os exceptions as this operation is not 
essential. so you could add your exception code there.

but i assume that the restore itself later will fail anyway, because the 
filename was probably corrupted within duplicity's restoring pipeline.

from here you could
A) create a test backup that sows the symptom or give us access to the original 
one to reproduce the issue and fix it
B) find out your self where in duplicity the filename gets corrupted

from my gut i suggest you to check the system charset settings (typically LANG 
env var) but there are a bunch of others. they could advise python to convert 
the filename internally which could have unexpected results, shouldn't but 
could.


..ede/duply.net