Announcement

Collapse
No announcement yet.

10554 Corrupt display of accented zipped filename char

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

  • chrisjj
    replied
    > There was a regression in 3.1.4 on non-US systems, and it will be fixed in
    > the next release.

    No fixed regression found in the changelog, but yes I find this problem fixed:



    Many thanks.

    Leave a comment:


  • chrisjj
    replied
    > The specific ones that BC can store that Explorer can't are:
    > plus a bunch of non-alpha characters like and .
    > ... When everything is working correctly the only time you'll see differences is
    > when you use the characters above or line drawing characters (╠ ┬
    > ▒).

    Good to hear. I look forward to the fix.

    Leave a comment:


  • Zo
    replied
    Originally posted by chrisjj View Post
    My tests results differ. On this Windows XP Home SP2 (territory unidentifiied on My Computer, General), in Explorer I select a file, press F2, and type SHIFT+AltGr+A, ENTER. The file is renamed to .
    The list of unsupported characters for Western European countries is fairly small. The specific ones that BC can store that Explorer can't are: plus a bunch of non-alpha characters like and . In Eastern Europe the differences are all non-alpha. In the US there are 34 alpha characters that BC can store that Explorer can't.

    I mentioned it previously, but to reiterate, the intended behavior is for BC to be compatible with Explorer as much as possible. v3.1.4 has a bug that broke that behavior, and it will be fixed in 3.1.5, so any testing you do in 3.1.4 is a waste of time. When everything is working correctly the only time you'll see differences is when you use the characters above or line drawing characters (╠ ┬ ▒).

    Leave a comment:


  • chrisjj
    replied
    > There was a regression in 3.1.4 on non-US systems, and it will be fixed in
    > the next release. Once it's fixed BC will display your zip correctly.

    Thanks.

    > but the situation is complex, and I don't think that makes us wrong.

    Scooter Software advertises BC3 as "ideal for comparing zip files" whilst knowing about zip compatibility problems not mentioned anywhere in the user docs AFAICT. Could Do Better, I think.

    Leave a comment:


  • chrisjj
    replied
    > I'm not really sure what's going on right now. A US/Western European install of Windows
    > should not be able to store a file who's name contains a character, and my tests here
    > confirm that.

    My tests results differ. On this Windows XP Home SP2 (territory unidentifiied on My Computer, General), in Explorer I select a file, press F2, and type SHIFT+AltGr+A, ENTER. The file is renamed to .

    > Please send me the zip

    Attached. The steps to reproduce the problem are:

    1 Create a file named
    2 Copy it into a .ZIP
    3 Compare the original and ZIP folders in BC3 10554

    BC shows the ZIP version as named differently and hence shows a false mismatch:

    http://img513.imageshack.us/img513/8240/58126361.gif

    > and let me know what the ANSI/OEM code pages are on your system
    > (the "Language for non-Unicode programs" option in the "Regional and
    > Language Options" control panel)

    English (United Kingdom)
    Last edited by chrisjj; 03-Aug-2009, 12:08 PM.

    Leave a comment:


  • chrisjj
    replied
    I'll take that as a No.

    Leave a comment:


  • Zo
    replied
    Chris,

    I'm not trying to be difficult, but your question, as phrased, doesn't have a yes/no answer.

    There was a regression in 3.1.4 on non-US systems, and it will be fixed in the next release. Once it's fixed BC will display your zip correctly.

    As to why I can't answer your question: The "host OS" does not define the way zip filenames are stored, the applications do. On Linux all the applications agree, and BC is fully compatible with them. On Windows there are two ways to store the filenames and there are large numbers of applications and zips that use each. BC3 tries to support both cases, but can't guarantee either 100%.

    As a concrete example, Explorer and BC2 use different methods. If you create a file named "╠", Explorer will store that as 0xCC. BC2 can't store that character, but if you create a file named "" it also stores it as 0xCC. So, in BC3 we get a zip containing 0xCC and have to decide whether that means "╠" or "", and in that case we'll go with "". Most of the characters will be detected and handled correctly, so "" should work regardless of which application created it. Neither method is more correct than the other. Explorer's approach is probably more wide-spread, but BC2's supports more useful characters. BC3 will use the Explorer method when possible.

    If you want to define "host OS" as "Explorer" then no, BC won't always match it, but the situation is complex, and I don't think that makes us wrong.

    Leave a comment:


  • Aaron
    replied
    Hello Chrisjj,

    Beyond Compare 3 is a multiplatform program. We run on a variety of Windows OS (some of which do *not* include zip support) and several Linux-based OS. We do not use Host specific calls to make zips since that would make zips incompatible as you upgrade your Host OS or between OS installs of Beyond Compare 3.

    We adhere to the standard spec that Zips are supposed to follow. Microsoft does not always follow this (Internet Explorer 6), but have shown that then usually come around to the spec later (Internet Explorer 7,8).

    We will investigate incorporating other behavior to help with legacy support. We are still fully compatible with any archives our software has created.

    Leave a comment:


  • chrisjj
    replied
    For the third time, I ask, is BC intended to be compatible with the ZIP format of its host OS, or not? A straight Yes or No answer would be appreciated.

    Leave a comment:


  • Zo
    replied
    BC is compatible with the official zip specification.

    Storing filenames with extended characters is not documented in that spec, and there is considerable disagreement on the best way to do so, so you will get inconsistent results with different programs. The method that BC uses for both reading and writing those filenames is the same as what WinZip does, and was decided early in BC2's development, before Windows had built-in zip support. Unfortunately Windows' uses a different method of storing those filenames and it isn't possible to detect which method is used. Changing which method we use now would break any files encoded using a previous version of BC.

    The zip spec recently documented the official way to support those filenames and BC is compatible with it. Windows' built-in support is not.

    Whether you take that to mean that BC is incompatible with the "zip format of the host OS" is up to you, but it is what it is, and it isn't changing. You could just as easily ask Microsoft to update their zip support so it uses the new spec, which would also solve the issue.

    Leave a comment:


  • chrisjj
    replied
    > Beyond Compare is compatible with WinZip.
    > You're welcome to buy a license to it and convince them to change their behavior.

    I don't know why you keep going on about WinZip. My issue is not with WinZip and I never ever mentioned it. I am using Windows XP Explorer zip.

    Is BC intended to be compatible with the ZIP format of its host OS, or not?

    Leave a comment:


  • Zo
    replied
    Beyond Compare is compatible with WinZip. You're welcome to buy a license to it and convince them to change their behavior. If they do we will too.

    Leave a comment:


  • chrisjj
    replied
    > Barring a bug or obvious enhancement, no, I'm not
    > going to change the behavior.

    Since the behaviour is in doubt, please could you simply confirm the design intent. Is BC intended to be compatible with the ZIP format of its host OS, or not?

    Leave a comment:


  • Zo
    replied
    I've looked into it further and I'm not really sure what's going on right now. A US/Western European install of Windows should not be able to store a file who's name contains a character, and my tests here confirm that. Please send me the zip and let me know what the ANSI/OEM code pages are on your system (the "Language for non-Unicode programs" option in the "Regional and Language Options" control panel).

    Barring a bug or obvious enhancement, no, I'm not going to change the behavior. I've studied the issue in depth and I agree with the reasons behind WinZip's behavior. We started matching WinZip's before Windows even had built-in zip handling, and changing it now would also break zips created in previous versions of BC.

    Leave a comment:


  • chrisjj
    replied
    > Yes, that's exactly what I'm saying.

    Do you have plans to fix this?

    Leave a comment:

Working...
X