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

[Z F]

Hello everybody

I am attaching an offending portion of the archive to this email. I have 
extracted it to a ext3 filesystem.
There were no errors, but the filename which starts with ppt9B looks strange.
the file is test_duplicity.tar.bz2 


I do not have the original computer of which the backup was made.
Nevertheless, the "offending" file came with a software package and  I have a 
newer version
of that package which has a file which I think is named the same way as the one 
which cannot be
extracted from the backup. (it is a help file) The file is stored in the 
test_duplicity_fileName.tar.bz2 file.

Because the computer from which the backup was made does not exist, it is hard 
to tell whether the
corruption happened at the source or during the duplicity backup or during the 
duplicity restore. Or maybe
there is no corruption at all and my current system is not configured correctly.


Maybe Edgar Soldin or someone else would be kind to take a look at this to try 
to understand what is going on?

the NTFS partition which I am using for restore is mounted with  as


ntfs-3g    defaults,locale=en_US.utf8,noauto,nodev,noexec


Is there a problem with these options?


Thank you very much for your kind help

Lazar





----- Original Message -----
> From: "address@hidden" <address@hidden>
> To: Discussion of the backup program duplicity <address@hidden>
> Cc: 
> Sent: Saturday, April 21, 2012 5:43 AM
> Subject: Re: [Duplicity-talk] restore OSError: [Errno 84]
> 
> 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
> 
> _______________________________________________
> Duplicity-talk mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>

test_duplicity_fileName.tar.bz2
Description: application/bzip

test_duplicity.tar.bz2
Description: application/bzip