Announcement

Collapse
No announcement yet.

13298 Mystery file quantity discrepancies

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

  • 13298 Mystery file quantity discrepancies

    Sometimes BC reports a quantity of files differing from Windows (dir /s /a).

    e.g. on today's work, Windows says 33821 files but BC FC status bar says two more. This is on FAT32, UK English region, lots of accents in filepaths FWIW.

    Any idea why? Else any suggestion as to how I can identify the orphan files, which perhaps would enlighten as to the cause?

    Thanks.

  • #2
    Use "dir /s /a /b" to get a flat list, then use BC's "Select All Files" and "Copy Filenames" commands to get its flat lists, then compare them in the text compare.
    ZoŽ P Scooter Software

    Comment


    • #3
      If I had to guess, it's probably files with paths longer than 256 characters. BC will pick them up and cmd.exe probably won't.
      ZoŽ P Scooter Software

      Comment


      • #4
        Originally posted by Craig View Post
        Use "dir /s /a /b" to get a flat list, then use BC's "Select All Files" and "Copy Filenames" commands to get its flat lists, then compare them in the text compare.
        Thanks. That false-mismatched due to different L-R sort orders, overcome by using instead Data Compare.

        But I'm also getting (apparently) false mismatches on non-ASCII characters, whether encoding display is left at using the default ("Don't override" -> Windows = ANSI v BC = UTF-8) or set to anything else that looks likely e.g. Windows = DOS/OEM. What's the correct encoding display to use?
        Last edited by chrisjj; 18-May-2011, 12:12 PM.

        Comment


        • #5
          If you redirect the DOS output to a file it will convert everything to the system ANSI encoding, which probably won't cover all of the characters that you need it to.

          The easiest way to work around it would be to strip out those characters in BC's output as well. After you copy them to the clipboard paste them into Notepad save it to a file. It should prompt about the loss of character data. After that just compare them in BC and it should work. You should be able to use the text compare instead of the data compare if you manually select the "Sorted" file format.

          If you want to see the original uncorrupted filenames it's a lot more work. You'll need to set the console window scrollback buffer as large as it will go and then manually copy the dir output in chunks. Unfortunately the max is 9999 lines, so you'll need to use some sort of filters to get the output in multiple passes.
          ZoŽ P Scooter Software

          Comment


          • #6
            Originally posted by Craig View Post
            If you redirect the DOS output to a file it will convert everything to the system ANSI encoding, which probably won't cover all of the characters that you need it to.

            The easiest way to work around it would be to strip out those characters in BC's output as well.
            They were few, so I could manually skip them. The result was two long filepaths that BC did read but that dir /s /b failed to read. I'm sad to find I cannot trust dir, and glad I have BC

            Originally posted by Craig View Post
            You should be able to use the text compare instead of the data compare if you manually select the "Sorted" file format.
            I had already done so. The mis-sort looks like a bug - now reported here http://www.scootersoftware.com/vbull...9829#post29829

            Originally posted by Craig View Post
            If you want to see the original uncorrupted filenames it's a lot more work. You'll need to set the console window scrollback buffer as large as it will go and then manually copy the dir output in chunks. Unfortunately the max is 9999 lines, so you'll need to use some sort of filters to get the output in multiple passes.
            Noted, even though I hope not to have to do this again.

            Thanks again Craig.
            Last edited by chrisjj; 18-May-2011, 12:23 PM.

            Comment

            Working...
            X