Fossil: Ticket Change Details

Changes to ticket 838bde7990

By kkinnell on 2008-12-04 03:00:21. See also: artifact content, and ticket history

Change comment to "@rem issue demostration del .\_fossil_ del .\test.fossil rmdir /Q /S .\testdir mkdir .\testdir del manifest.uuid del manifest cd .\testdir echo 345678>"1rřřřř R .test" cd .. fossil new test.fossil fossil open test.fossil fossil add .\testdir\\"1rřřřř R .test" fossil ls fossil commit -m "check in a file with accended char/s and spaces in its name" --nosign fossil ui ---- on win XP I create file with some accending characters in its name, commit it to the fossil repository and save repository as a zip file. When I extract such file from fossil generated file by windows Explorer/Total Commander I get file with different name. Extracting by unzip program from Info-ZIP web site yields correctly named file. In above example I create file with "r-caron" chars in its name(U+0159), after unzipping I get file with "DEGREE SIGN"(U+00B0) in it instead. Many other characters get twisted in similar way. I wonder, if there should be something marked in zip file header, as how to interpret stored file name. I tried to check differences with explorer generated zip files/fossil generated ones with help of: unzip -Zv byZIP.zip >byZIP.lst unzip -Zv byFossil.zip >byFossil.lst so far to no avail. <hr>anonymous claiming to be kkinnell added on 2008-12-03 02:56:00: If I'm reading this correctly, you stored a file containing utf8 or uc16 encoded characters in a repository, and then got the zip for the repository by downloading it from the server. Then, when you unzipped it with one windows program, the file was encoded incorrectly, but when you unzipped it with a different windows program, the encoding was correct. If that is what happened, then the problem is how the programs you are using for unzipping the files are interpreting them. The one that gives you the correct version is using the same encoding that you used when you created the file, the other one is using something else. fossil itself uses SQLite BLOBs to store its artifacts. The storage doesn't encode the data in any way, it treats it as binary data. <hr>anonymous added on 2008-12-03 04:53:53: The content of file(s) is correct. What causes trouble is the name/path of file having accented characters. If I modify the test and try to add file on path already having mix of accended/not accended characters and spaces, it is even not listing such file in File List menu which I would consider a bug. (I can save zip archive from fossil, view file content(diff) but will not see such file listed in File List menu) Produced zip archive can be correctly extracted by unzip from Info-ZIP web site. Windows Explorer will show just badly transcoded file name on badly transcoded file path. Used test path uses "r-caron" chars (U+0159),"s-caron"(U+0161) and "LATIN SMALL LETTER Y WITH ACUTE" (U+00FD) accented characters. del .\_fossil_ del .\test.fossil rmdir /Q /S .\\"testSšššSRřřřR YýýýY" mkdir .\\"testSšššSRřřřR YýýýY" del manifest.uuid del manifest cd .\\"testSšššSRřřřR YýýýY" echo content of file>"1rřřřř R .test" cd .. fossil new test.fossil fossil open test.fossil fossil add .\\"testSšššSRřřřR YýýýY"\\"1rřřřř R .test" fossil ls fossil commit -m "check in a file with accended char(s) and spaces in its name on a path with accedended characters and spaces" --nosign fossil ui --- fossil ls ADDED testSÜÜÜSR°°°R YřřřY/1r°°°° R .test <hr>kkinnell added on 2008-12-03 16:20:32: I have tested this in the Linux version, via copy and paste using the exact string you are using (testSšššSRřřřR YýýýY). I can confirm that the encoding used for display of the filename and contents are not the same as the encoding used for wiki, the wiki strings are "entified" as &#ddd; decimals whereas display of the file path strings are dependent on the browser's default encoding. When I set my browser to use the default windows encoding (Western, or Latin-1 which is ISO-8859-1) I get behavior similar to that which you describe. I think it is possible you <code>add</code>ed the file that is not showing up in the file list, but did not <code>commit</code> commit the change afterward. This is the only way I have been able to replicate this behavior. Please verify that all of your encodings—system, browser and zip programs, are the same as your input system and see if you still get bad behavior. I can duplicate most of the problems you are having by mis-matching the encodings, but I am on a GNU/Linux system and I can't be sure there is not something peculiar to the windows version causing part of your problem."