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
