Hi again, Ok, there was a bug in recent code. The new data shows nothing different from your previous report, but this is uncomfortable for me, as I do not have a similar configuration.
Can you please retry with : http://jp-andre.pagesperso-orange.fr/dedup121-beta.zip Also note that the reparse data is necessary to focus to the right place in the *.ccc file. When you need to report a case, please also post the reparse data of an unreadable file. Jean-Pierre Jelle de Jong wrote: > Dear Jean-Pierre, > > No luck so far, I hope I provide the needed debug information as if: > > # the file test, syslog and streams generation: > http://paste.debian.net/plainh/d495e075 > > # the stream.data.full.00120000.00010000.gz file: > https://powermail.nu/nextcloud/index.php/s/OA0iRf9yKYkc5IL > > # the stream.data.full.00140000.00010000.gz file: > https://powermail.nu/nextcloud/index.php/s/tFtwjctpQ4rTzoD > > Thank you for your help! Really hope to get this working right. > > Kind regards, > > Jelle de Jong > > On 09/02/17 16:49, Jean-Pierre André wrote: >> Hi again, >> >> Jelle de Jong wrote: >>> Hi Jean-Pierre, >>> >>> Don't know if this is related to the bug you found. >>> >>> But I am getting scrambled data, one moment the file is empty then it >>> has data and the file sizes are not the same when copied: >> >> Probably the same bug, though difficult to tell for sure. >> >> Please retry with the (hopefully) fixed plugin in >> http://jp-andre.pagesperso-orange.fr/dedup.zip >> >> Regards >> >> Jean-Pierre >> >>> >>> root@backup:~# ls -hal "/mnt/sr7-sdb2/ALGEMEEN/DSC_1319.JPG" >>> -r-xr-xr-x 1 root root 2.4M Feb 5 2014 >>> /mnt/sr7-sdb2/ALGEMEEN/DSC_1319.JPG >>> root@backup:~# cp "/mnt/sr7-sdb2/ALGEMEEN/DSC_1319.JPG" /root/ -v >>> '/mnt/sr7-sdb2/ALGEMEEN/DSC_1319.JPG' -> '/root/DSC_1319.JPG' >>> root@backup:~# ls -hal DSC_1319.JPG >>> -r-xr-xr-x 1 root root 0 Feb 9 13:31 DSC_1319.JPG >>> root@backup:~# file "/mnt/sr7-sdb2/ALGEMEEN/DSC_1319.JPG" >>> /mnt/sr7-sdb2/ALGEMEEN/DSC_1319.JPG: empty >>> root@backup:~# file "/mnt/sr7-sdb2/ALGEMEEN/DSC_1319.JPG" >>> /mnt/sr7-sdb2/ALGEMEEN/DSC_1319.JPG: data >>> root@backup:~# cp "/mnt/sr7-sdb2/ALGEMEEN/DSC_1319.JPG" /root/ -v >>> '/mnt/sr7-sdb2/ALGEMEEN/DSC_1319.JPG' -> '/root/DSC_1319.JPG' >>> root@backup:~# ls -hal DSC_1319.JPG >>> -r-xr-xr-x 1 root root 256K Feb 9 13:32 DSC_1319.JPG >>> >>> Kind regards, >>> >>> Jelle de Jong >>> >>> On 09/02/17 11:41, Jean-Pierre André wrote: >>>> Hi, >>>> >>>> Jelle de Jong wrote: >>>>> Hi Jean-Pierre, >>>>> >>>>> Thank you! >>>>> >>>>> The new plug-in seems to work for now, I am moving it into testing >>>>> phase >>>>> with-in our production back-up scripts. >>>> >>>> Please wait a few hours, I have found a bug which >>>> I have fixed. I am currently inserting your data >>>> into my test base in order to rerun all my tests. >>>> >>>>> Will you release the source code eventually, would like to write a >>>>> blog >>>>> post about how to add the support. >>>> >>>> What exactly do you mean ? If it is about how to >>>> collect the data in a unsupported condition, it is >>>> difficult, because unsupported generally means >>>> unknown territory... >>>> >>>>> What do you think the changes are of the plug-in stop working again? >>>> >>>> (assuming a typo changes -> chances) >>>> Your files were in a condition not met before : data >>>> has been relocated according to a logic I do not fully >>>> understand. Maybe this is an intermediate step in the >>>> process of updating the files, anyway this can happen. >>>> >>>> The situation I am facing is that I have a single >>>> example from which it is difficult to derive the rules. >>>> So yes, the plugin may stop working again. >>>> >>>> Note : there are strict consistency checks in the plugin, >>>> so it is unlikely you read invalid data. Moreover if >>>> you only mount read-only you cannot damage the deduplicated >>>> partition. >>>> >>>>> We do not have an automatic test running to verify the back-ups at >>>>> this >>>>> moment _yet_, so if the plug-in stops working, incremental file-based >>>>> back-ups with empty files will slowly get in the back-ups this way :| >>>> >>>> Usually a deduplicated partition is only used for backups, >>>> and reading from backups is only for recovering former >>>> versions of files (on demand). >>>> >>>> If you access deduplicated files with no human control, >>>> you have to insert your own checks in the process. I >>>> would at least check whether the size of the recovered >>>> file is the same as the deduplicated one (also grep for >>>> messages in the syslog). >>>> >>>> Regards >>>> >>>> Jean-Pierre >>>> >>>>> Again thank you for all your help so far! >>>>> >>>>> Kind regards, >>>>> >>>>> Jelle de Jong >>>>> >>>>> >>>>> On 08/02/17 15:59, Jean-Pierre André wrote: >>>>>> Hi, >>>>>> >>>>>> Can you please make a try with : >>>>>> http://jp-andre.pagesperso-orange.fr/dedup120-beta.zip >>>>>> >>>>>> This is experimental and based on assumptions which have >>>>>> to be clarified, but it should work in your environment. >>>>>> >>>>>> Regards >>>>>> >>>>>> Jean-Pierre >>>> >>>> >>> >> >> > ------------------------------------------------------------------------------ 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
