Hi, Please try http://jp-andre.pagesperso-orange.fr/dedup123-beta.zip
Regards Jean-Pierre Jean-Pierre André wrote: > Hi, > > I see what is happening here : this file "algemeen.txt" > is recorded the traditional way (like mine), not the > way most of your files are recorded. So I have to improve > the selection of modes. > > I will upload a fix next week. > > Was this file created recently ? Maybe, when a file is > updated, it is recorded differently from when it was created > initially. > > Regards > > Jean-Pierre > > Jelle de Jong wrote: >> Beste Jean-Pierre, >> >> #getfattr -h -e hex -n system.ntfs_reparse_data ... >> #dd if=/dev/mapper/.. skip=30817428 bs=4096 count=1 | od -t x1 >> #and the other commands outputs: >> https://powermail.nu/nextcloud/index.php/s/HwzpBqaIzOyZedg >> >> # stream.data.full.00190000.00010002.gz: >> https://powermail.nu/nextcloud/index.php/s/KKlByC8qEPKZFrC >> >> Thank you in advance, >> >> Kind regards, >> >> Jelle de Jong >> >> On 28/03/17 16:32, Jean-Pierre André wrote: >>> Jelle de Jong wrote: >>>> Hi Jean-Pierre, >>>> >>>> When trying to read algemeen.txt I get a reproducible "Bad stream for >>>> offset" (I got a few more files with the same issue) >>> >>> So, please post the reparse tag for this file algemeen.txt : >>> getfattr -h -e hex -n system.ntfs_reparse_data somepath/algemeen.txt >>> >>> Also please post the contents of file 1545290. I do not >>> know its name, but it must be in the Stream directory, >>> with a suffix .ccc. To get its name do : >>> ls -li *as*usual*/Stream/*.ccc | grep 1545290 >>> >>>> >>>> # ntfsinfo -fvi 0 /dev/mapper/lvm1--vol-sr7--disk2--snapshot--copy2 >>>> http://paste.debian.net/plainh/486b1a01 >>> >>> So inode 1582022 must be in cluster 30826611 and >>> inode 1545290 in cluster 30817428. >>> Please post the outputs of : >>> dd if=/dev/mapper/lvm1--vol* skip=30826611 bs=4096 count=1 | od -t x1 >>> dd if=/dev/mapper/lvm1--vol* skip=30817428 bs=4096 count=1 | od -t x1 >>> >>> The sequencing error which had been detected may have >>> disappeared with no evidence left, but it is worth >>> trying. >>> >>>> I feel we may be almost there (support for data deduplication), but >>>> still hitting a few unreadable files... >>> >>> I hope so, this is an uneasy situation for me, as I >>> cannot reproduce the errors. Thanks for you cooperation >>> to the bug hunt. >>> >>> Jean-Pierre >>> >>>> >>>> Thanks you again! >>>> >>>> Kind regards, >>>> >>>> Jelle de Jong >>>> >>>> >>>> On 23/03/17 22:03, Jean-Pierre André wrote: >>>>> Hi, >>>>> >>>>> Jelle de Jong wrote: >>>>>> Hi Jean-Pierre, >>>>>> >>>>>> Thank you again! >>>>>> >>>>>> Could you take a look at the following output, I got some "Bad stream >>>>>> for offset" messages: http://paste.debian.net/plainh/c145e066 >>>>>> >>>>>> Follow-up on the previous mail >>>>>> >>>>>> I was not able to get any node information, and have not been able to >>>>>> reproduce the NTFS messages. >>>>>> >>>>>> ntfsinfo -fvi 1582022 >>>>>> /dev/mapper/lvm1--vol-sr7--disk2--snapshot--copy2 >>>>>> Error loading node: No such file or directory >>>>> >>>>> Before digging into the "Bad stream for offset" messages, >>>>> I would like to get details about those inconsistencies >>>>> before they are wiped out (hoping it is not too late). >>>>> Maybe the issues are related, maybe they are not. >>>>> >>>>> The ntfsinfo error means either that the faulty inodes >>>>> have been freed or they are extents to other inodes. >>>>> >>>>> I will have to do it in two steps : first determine where >>>>> they are located, then extract their contents. >>>>> >>>>> To get the mapping of inodes, please post the output of >>>>> ntfsinfo -fvi 0 /dev/mapper/lvm1--vol-sr7* >>>>> >>>>> Jean-Pierre >>>>> >>>>>> >>>>>> Kind regards, >>>>>> >>>>>> Jelle de Jong >>>>>> >>>>>> On 21/03/17 12:01, Jean-Pierre André wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Jelle de Jong wrote: >>>>>>>> Dear Jean-Pierre, >>>>>>>> >>>>>>>> I am still testing the dedup plugin, I have issues with >>>>>>>> rdiff-backup >>>>>>>> that the checksum of the source and destination are not the same, >>>>>>>> but >>>>>>>> this can be an issue with rdiff-backup. >>>>>>>> >>>>>>>> However I did get these messages, but I do not know if they are >>>>>>>> related >>>>>>>> to the dedup plugin? >>>>>>>> >>>>>>>> Mar 21 06:57:37 backup ntfs-3g[12620]: Record 1582022 has wrong >>>>>>>> SeqNo >>>>>>>> (159 <> 156) >>>>>>>> Mar 21 06:57:37 backup ntfs-3g[12620]: Could not decode the type of >>>>>>>> inode 1582022 >>>>>>>> Mar 21 06:57:37 backup ntfs-3g[12620]: Record 1545290 has wrong >>>>>>>> SeqNo >>>>>>>> (296 <> 295) >>>>>>>> Mar 21 06:57:37 backup ntfs-3g[12620]: Could not decode the type of >>>>>>>> inode 1545290 >>>>>>> >>>>>>> These errors are thrown by ntfs-3g proper, not by the >>>>>>> deduplication plugin. >>>>>>> >>>>>>> Inconsistencies have been found in the mentioned files, >>>>>>> and they are unlikely to be created by the plugin (which >>>>>>> does not have updating support), ... but one never knows. >>>>>>> Owing to the inconsistencies, ntfs-3g cannot tell if the >>>>>>> said files are plain files, directories, sockets, etc. >>>>>>> >>>>>>> You have to run chkdsk to fix these inconsistencies, but >>>>>>> this can lead to losing data, so before doing that, the >>>>>>> parameters of these files should be analyzed to assess >>>>>>> the possible damage. >>>>>>> >>>>>>> Please post the outputs of : >>>>>>> ntfsinfo -fvi 1582022 /dev/partition >>>>>>> ntfsinfo -fvi 1545290 /dev/partition >>>>>>> >>>>>>> This must be done as root, replacing /dev/partition by >>>>>>> the actual partition path (something like /dev/sdc2) >>>>>>> >>>>>>> Jean-Pierre >>>>>>> >>>>>>>> >>>>>>>> Kind regards, >>>>>>>> >>>>>>>> Jelle de Jong >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ ntfs-3g-devel mailing list ntfs-3g-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
