DirectorySeparator is system dependant constant, so on Windows it's \ but on Linux, macOS, FreeBSD etc it's /.
Internally it should replace those IN-correct Directory separators, but it doesn't !!!
Gotcha. It would be nice to have in that case for Windows (I no longer recall what OS/2 used for directory separators).
On the other hand, you did specify the incorrect separator :)
Is the author known? If so, you could contact him/her and suggest an enhancement.
Can anyone else help?Help with what? If you found a bug, just go to the bugtracker: https://bugs.freepascal.org/my_view_page.php , select FPC and report it.
Well, I was hoping that the oldest members of the Forum would know that, since this is the only info I got and it's the header of the Zipper unit(who's this micheal?):Again bugtracker, FPC section and search for Michael. You will see him assigned to many bug reports. He is really the Michael you are looking for, I know because I also reported issues related to paslib in the past. :)
Again bugtracker, FPC section and search for Michael. You will see him assigned to many bug reports. He is really the Michael you are looking for, I know because I also reported issues related to paslib in the past. :)
O:-)
They like patches when bugs are reported. The link is on your left side for FPC — I am sure you had seen it before. There is a section for packages in the bug tracker. You'll need a new user name/password to be able to create a bug report.
If you do report this bug, don't forget to leave the issue number here for us. Thank you in advance. 😃
I've been using forward slashes in Windows for zipper usage in fpspreadsheet all the time, and there have never been any reports of unreadable files in Linux. Also, the attached project results in a valid zip in windows and Linux.
So the problem is that AddFileEntry does not convert back slash to forward slashes? Calling something like SwitchPathDelims in LazFileUtils (or a similar function because zipper is in FCL) would be a fix to your bug report.
Found this one:
procedure TZipFileEntry.SetDiskFileName(const AValue: String); begin if FDiskFileName=AValue then Exit; // Zip file uses / as directory separator on all platforms // so convert to separator used on current OS if DirectorySeparator='/' then FDiskFileName:=AValue else FDiskFileName:=StringReplace(AValue,'/',DirectorySeparator,[rfReplaceAll]); end;
And this looks as if your issue is already considered...
But the slash to be replaced by StringReplace is the wrong one!
FDiskFileName := StringReplace(AValue, '\', '/', [rfReplaceAll]);
There are several locations like this. Not sure, though, which one is the name to be used for zipping and which one for unzipping.
If you want to debug the zipper unit you should copy the zipper.pp file into your test project directory. This unit is at the "end of the food chain" and can be recompile without affecting others.
It works on Windows and Linux - try this test
The worst software is the one which tries to guess what the user means.
My conclusions do not matter since I cannot write to the fpc repository... But I submitted a patch similar to reply #21 to your report hoping that an fpc dev picks it up and finds it useful.
It does not address the DOS issue mentioned by marcov since it has been there already before your report.
It seems that this is not the only problem of this package. Try filenames with non-ASCII characters at Windows...
This has nothing to do with zipper. It is a standard problem in FPC string handling. If you use zipper in an LCL GUI program everything works fine because the standard encoding is UTF8. The problem mentioned appears in standalone commandline programs in which FPC does not switch to UTF8 by default.
Simply call SetMultiByteConversionCodePage(CP_UTF8) as the first line of your program and the zipper handles utf8-encoded file names correctly. See also attached demo.