disParity » Bug Reports

.40 Testing

(7 posts)
  • Started 1 year ago by pccfatman
  • Latest reply from pccfatman
  1. Ok my experience with .40 thus far

    Set to notify of changes, working as expected
    Set to update after 1 minute of inactivity, working as expected
    Changed the files on the drive when update in progress, it saw the changes and ran another update after 1 minute of inactivity

    Made no changes to the drive but browsed to a directory and got properties of a file, disParity saw this as a change and re-scanned that drive after 1 minute (could this be due to drive bender I wonder or is getting file properties an actual change to the drive), at any rate it scanned and found no changes.

    I will post anything else I find as I continue to try and break it :)


    Edit: So it seems that even accessing a file on my drive is detected as a change and disParity will rescan that drive. I will do more testing and see if this is related to how windows access data or if maybe Drive Bender is writing files to the drive when I access things. I do have DP set to ignore *.$DRIVEBENDER files as those do change frequently

    Edit Again: This appears to only happen when I access files via my Drive Bender pool, if I share the individual drives directly and perform the same tests DP does not see any changes to the drive. I played a movie and got properties on it from both my computer via network share and directly from the server itself using both the individual drive and then the same file from the pool. This only happens on the pool so I will look into DB and see what's going on there.

    So it would appear that most of these drive changes are definitely related to Drive Bender. I'm not sure how to get around this issue other than to set the scan time to a higher number to reduce the number of scans being performed. If I find a solution, I'll post back for anyone else using DB with disParity

    On a brighter note .40 seems to be working smashingly :)

    Thanks Roland for all your hard work

    Ok so did some more testing today....

    A) Attempted to move a file while DP was scheduled to update that specific file, it would not allow move but it would copy it. I'm glad to see this in case someone on my network goes moving things around while DP is updating.

    B) Still no solution to the Drive Bender problem. It's not detrimental but it does cause excess scans

    C) Renaming a file will cause DP to scan the drive and update parity regardless if it is in scan mode or update mode (Is this expected behaviour?) for instance if I rename a file and click scan all DP will recognize this change and fix it even though I didn't tell it to update

    D) Renaming a file and then moving it to another location on the same drive will show the same results as "C" above

    E) Renaming and moving a file in a single operation (using a program like filebot) shows as 1 file deleted and 1 file added

    F) Renaming a file with filebot and leaving it in place also has the same effect as "E" above

    Judging by what I can tell, filebot uses a read/write operation from on file to another and then removes the original file (not sure about this but it appears so) so I would guess this is expected behaviour from disParity. Although is is very disappointing on filebot's behalf since it takes substantially longer to update parity because of this.

    The only possible problem I see is "C" and "D" above, as this is during a scan process and I would not expect DP to make any changes, only to report them.

    Sorry for mentioning all these other programs. If it bothers you I will not do it. I just feel it's important to document DP's interaction with the other programs that will most likely be used by people.


    Posted 1 year ago #
  2. An update to the Filebot situation.
    It would appear that Filebot updates file dates and times as well as writes some metadata to NTFS Extended Attributes. this can be disabled in the ini settings for the program. Also it is disabled by default if you launch the program using filebot.platform.launcher.exe in the install directory as these features are disabled by default as well as windows native file copy.

    Hope this helps anyone else in need


    Posted 1 year ago #
  3. Roland

    Regarding A: this is a normal effect of having a file open and locked for reading. Windows prevents other apps from modifying or deleting the file while the first app is reading it. Other apps are still allowed to read it.

    Regarding C and D: renaming a file and moving a file (to another location on the same drive) are actually the same thing. They both fall under the case "the file was at path A and now it is at path B." This case is handled during a scan, not an update. The parity data is not modified so no update needs to happen. The entry for that file in the metadata is updated with the new path, and that's it. Short answer: yes, this is expected behavior.

    Regarding E and F: this is odd. The only way disParity is going to treat that case as a "1 delete and 1 add" is if the file has been modified. So fileBot *must* be modifying the file in some way when you do this operation. Even if it deletes the old file and writes the new one, if the new one is an exact copy of the old, disParity won't treat it that way (it would fall under the move/rename case instead.) I don't use fileBot so I can't say more than that.

    Posted 1 year ago #
  4. Great news thus far,

    In all my attempts to break it DP is running strong. I have not had any problems that I have not been able to work around, and in any case the problems I did have were not DP problems.

    I will continue to test it out and let you know any anomalies I may come across. My next test is a simulated drive failure with full data (test data of course). I'll let ya know how it goes.

    Congrats Roland on a great release :)

    Posted 1 year ago #
  5. Roland

    Thank you. My only regret is that it took so long. Switching from a purely passive user-driven event model to one where the product can now spontaneously take action on its own introduced more tricky issues than I would have imagined. I've also been more busy with work than usual in the past year (this is a good thing, I guess.)

    Anyway, glad to hear everything is working well so far. Once we get this round of changes stabilized and out of beta, I can finally focus on some other improvements I've been wanting to make for a while now!

    Posted 1 year ago #
  6. ajiau

    FWIW I've been running .40 beta for nearly a week and it's working flawlessly.

    Posted 1 year ago #
  7. Well it's been about 3 weeks or so and I'm happy to report I haven't been able to break it. .40 is running strong and I feel confident in it's ability to keep my data safe :)

    Thanks Roland

    Posted 1 year ago #

RSS feed for this topic


You must log in to post.