duplicity-talk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Z F
Subject: Re: [Duplicity-talk] restore OSError: [Errno 84]
Date: Fri, 20 Apr 2012 12:24:34 -0700 (PDT)

Hello everybody




>________________________________
> From: "address@hidden" <address@hidden>
>To: Discussion of the backup program duplicity <address@hidden> 
>Sent: Wednesday, April 18, 2012 11:19 AM
>Subject: Re: [Duplicity-talk] restore OSError: [Errno 84]
> 
>On 18.04.2012 17:14, Roy Badami wrote:
>> On 17/04/2012 21:10, Kenneth Loafman wrote:
>>>
>>> The problem is that you have some Unicode chars in the filename and I'm not 
>>> sure if NTFS supports Unicode.
>>>
>> 
>> NTFS certainly does support Unicode - in fact I'm pretty sure it natively 
>> uses 16-bit characters, as does pretty much everything in Windows NT 
>> onwards.  (No idea if/how duplicity handles unicode in Windows filenames 
>> though)
>> 
>> 
>
>that's right, although the mapping between filesystem charsets can be tricky 
>sometimes...
>
>anyway, 
>A) what does duplicity report when you --list-current-files your backup? is 
>this filename clean?
>B) what is the offending file name supposed t look like?




I am using ntfs-3g when mounting the partition.

The output of duplicity list-current-files produces a clean name 

ppt9B [Rp].ppt


The restore process is trying to make 

ppt9B [R\xe9cup\xe9r\xe9].ppt

the real name of the file is most likely (not sure) to be ppt9B\ 
\[Rلcupلrل\].ppt

Note strange shaped-letter J in the name which happens three times after R 
after p and after r.
Duplicity codes it as \xe9.

I have tried creating a filename with this name on the NTFS partition where I 
am restoring and it was created
reproducing the strange J thing...

As far as I remember, the offending file came from a french version of windows 
(so should not be a problem with NTFS).
However, it was a few years ago, so I might be wrong, but I am sure it came 
from France :)


As far as I can tell, this raises two questions:

1. What is happening in duplicity and why it cannot recover the file?
2. Is there a way to skip/rename/ignore the error produced when duplicity tries 
to extract this file, so that the
rest of restore can proceed?



Unfortunately,  I do not have access to a new drive right now and cannot 
reformat the current one.
I have thought of making an ext3 image, but ntfs-3g does not support files 
larger than 2G very well.
It works, but so slow that it is useless.  I have investigated a possibility of 
building and LVM volume
over a number of 2G files but there are only 8 loop-back devices and I would 
need something like 80
(need 160G) so lvm is out. As far as I understood, I cannot build lvm on top of 
regular files directly, they have to be
bound to a loop-device. I could try to make a virtual machine and make its 
drive split into 2G files to play
nicely with NTFS-3g and extract like this.... Is this my only option short of 
getting a drive?



Thank you very much for your help

Lazar



reply via email to

[Prev in Thread] Current Thread [Next in Thread]