Announcement

Collapse
No announcement yet.

BC4 bails out for large files?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • BC4 bails out for large files?

    Continuing my testing of BC4 I found that it erroneously declares two large files identical if no differences are found within the initial 13-15MB of data. I'm not sure about the limits, they also seem to vary. Uploading an example pair is hopeless but you can artificially create a pair like below:

    dd if=/dev/zero bs=1M seek=32 count=0 of=bc4test.a
    echo a >> bc4test.a
    dd if=/dev/zero bs=1M seek=32 count=0 of=bc4test.b
    echo b >> bc4test.b

    bcompare bc4test.a bc4test.b

    and see what happens.

    On my system the files are reported equal while only the initial ~13MB diff is shown in the Hexview.

    BC3 does work fine in such cases.

    btw, would be nice to know what are the size limits that BC3, BC4 are supposed to handle safely (naturally, assuming plenty of RAM memory is available).

    Regards,
    /Mikko

  • #2
    I am not seeing the same behavior on my test system. Running these commands on these files results in detecting they are different and launching the Hex Compare. Can you email us at support@scootersoftware.com with your BCSupport.zip (Help menu -> Support; Export)? Please include a link back to this forum thread in the email for our reference.

    What kind of custom brew Fedora are you running?
    Aaron P Scooter Software

    Comment


    • #3
      I'm running ~Fedora 23 with custom updates from rawhide but nothing really special, as far I can tell...
      BCSupport.zip is attached and the failure happens from a clean, generic 'user' account with a trial license and Pro features on.

      If I reopen the session from within BC4 then the comparison works fine, looks to fail only when started with the files as arguments on command line, perhaps another startup synchronisation thing...

      I've tried the trick with older glibc (official Fedora releases) but with vers. 2.20 BC4 crashes at start and with 2.21 it fails just as described with 2.22.

      /M
      Attached Files
      Last edited by mikko; 20-Nov-2015, 12:39 PM.

      Comment


      • #4
        Ubuntu 12.04.5 64-bit
        BC Version 4.1.2 (build 20720) 64-bit

        I get the same results as mikko on those two test files (bc4test.a and bc4test.b). BC4 says the files are identical, and only displays the first 13303807 (hex CAFFFF) bytes.

        By comparison:
        Code:
        $ diff -s /tmp/bc4test.a /tmp/bc4test.b
        Binary files /tmp/bc4test.a and /tmp/bc4test.b differ
        Last edited by Dave_L; 20-Nov-2015, 03:55 PM.

        Comment


        • #5
          Thanks, Dave.

          I tried several more times. One of these times I may have reproduced these results (or, in my many tests, made a mistake and accidentally called on two equal files ). I'll open a tracker entry to see if we can investigate. Did you use the exact command lines from the first post to generate the sample files?
          Aaron P Scooter Software

          Comment


          • #6
            I just repeated the test, using these commands:

            Code:
            cd /tmp
            dd if=/dev/zero bs=1M seek=32 count=0 of=bc4test.a
            echo a >> bc4test.a
            dd if=/dev/zero bs=1M seek=32 count=0 of=bc4test.b
            echo b >> bc4test.b
            bcompare bc4test.a bc4test.b &
            BC reports "Binary same".

            The last byte displayed has offset 012AFFFF (decimal 19595263).

            I'm attaching a .zip containing the two test files.
            Attached Files

            Comment


            • #7
              Thanks. I'm not seeing this 100% of the time on different systems, but I have managed to make it happen a few times on Ubuntu 12.04. Hopefully we can track this down and figure out what is happening here.
              Aaron P Scooter Software

              Comment


              • #8
                Any progress on this? It's a concern for me that BC could report different files as being identical.

                Comment


                • #9
                  We're still investigating. Our main Linux developer was mid-project on a few things, but he's wrapped up enough to help dig into this.
                  Aaron P Scooter Software

                  Comment


                  • #10
                    I don't like pestering you about this, but I think it's a serious problem. It's worse than crashing. If BC crashes, at least you know the comparison failed. In this case, BC is providing bad information.

                    So, any progress?

                    Comment


                    • #11
                      It will be fixed in 4.1.3, which we've just cut off for testing.
                      ZoŽ P Scooter Software

                      Comment


                      • #12
                        Thanks

                        Comment


                        • #13
                          Looking forward for the update as for big files BC4 is consistently ignoring differences at offsets larger than 13MB or so...

                          Another nuisance for BC4 as well as BC3 is the lack of X selection update i.e. when selecting text from the BC views the X selection is not updated making text transfers always requiring Ctrl-C+Ctrl-V type of key presses. Would be so nice if BC would properly play along with the other X apps and allow using only the mouse for transferring text around (as it's so much more convenient)...

                          Thanks.
                          /M

                          Comment


                          • #14
                            We're currently in QA and hope to have the release out soon.

                            And thanks for the selection/copy suggestion; I'll add it to our wishlist.
                            Aaron P Scooter Software

                            Comment


                            • #15
                              BC 4.1.3 performs correctly with the two test files described in post #6.

                              Comment

                              Working...
                              X