Merged wrong patch

[Alexander Belchenko]

John Arbash Meinel пишет:
...
> 
> Obviously the test suite was incomplete, which allowed me to make a
> mistake like this. (You can also just do 'cd $bzr.dev; bzr export
> foo.zip; unzip foo.zip, and it will fail).
> 
> So I'm submitting the attached patch, which fixes zipfile support, so
> they create correct files at least in ASCII encoding. It includes a test
> case, so that we don't have regressions like this again.
> 
> Now, this works with plain 'unzip', but it still won't work with
> Windows, because win32 expects other bits to be set in the
> 'external_file_attributes' section. Basically it expects:
> 
> #define S_IFDIR 0040000
> #define ZIP_DIRECTORY_BIT       (1 << 4)
> external_file_attributes = S_IFDIR | ZIP_DIRECTORY_BIT
> 
> I wrote a library once for parsing zipfiles, and I've found that without
> those things, windows is really hopeless.
> 
> And just testing now, I'm not sure how you were using zip files. I think
> you are on Win2000, so you probably are using some third party software
> (like WinZip). But WinXP has native support, and didn't like the zip
> files that we used to generate.

I use Windows Commander that could go into zip files as to directories.

> But I tested this one. And while for some reason WinXP is much slower at
> extracting the contents than any of the other methods (7zip, cygwin
> unzip, etc), it works.
> 
> Because UTF-8 is a strict superset of ASCII, zipfiles will always work
> on all platforms as long as the filenames are ascii.
> 
> The problem is that if we switch to OEM encoding, then they only work on
> Windows that uses the same encoding. So if you create a zipfile in
> russian, I will get different filenames on my English windows. And
> certainly unzipping under Linux won't really create the right names
> either. (Linux is more accepting of just plain bytestreams, so it is
> possible to tell it to interpret the paths differently)

Yes. Exactly. That's why I think we should not support export to zip
non-ascii filenames.

Bzr has ability to export to directory. And user could export their tree
to directory and then use their own zip archiver to make zip. At least
in this case bzr honestly warn user that bzr cannot guarantee correct
export result.

> 
> Which means that if you are trying to export to .zip to share with other
> people, you are pretty much universally screwed one way or another if
> you have non-ascii filenames. I can understand wanting to use OEM
> because then it at least works for the local machine, and people who
> have similarly configured machines. I personally prefer to make an
> attempt at cross-platform compatibility and being able to store any
> valid unicode filenames, not just ones that fit in the current OEM
> markup. (I can write bågfors.txt and حوجو.txt next to eachother, so I
> feel I should be able to put them into a zipfile together)
> 
> I tested this on linux and windows and it works on both platforms.
> 
> So I'm not completely opposed to using oem encoding on windows. But I
> think we need to think about it a bit. For now, I prefer being consistent.

I think that sometimes bzr try to implement too much functionality. And
this can be really too much.

I was one of person who wrote zip exporter code. And not exporting
unicode tree to zip was deliberate decision because of OEM problem. If
user want zip he should export to directory and then zip that directory
with their own archiver.

--
Alexander