...there should be an expanded disk space requirement method before you decompress...What do you mean by that? Sorry, I don't understand this...
For unzipping a certain file I use the following program:
{$mode objfpc}{$H+} uses classes,sysutils,zipper; function unzip_file(fspecZ,fspecP,destDir: ansistring): ansistring; {unzips packed file 'fspecP' from zipfile 'fspecZ' to destination 'destDir'} var Z: TUnZipper; SL: TStringList; begin Z:=TUnZipper.Create; SL:=TStringList.Create; try SL.Add(fspecP); Z.FileName:=fspecZ; Z.OutputPath:=destDir; Z.UnZipFiles(SL); Z.Free; SL.Free; exit(''); {if no Error} except on E: EZipError do begin Z.Free; SL.Free; exit('Error 1 ' + E.Message); end; on E: Exception do {all other Exceptions: } begin Z.Free; SL.Free; exit('Error 2 ' + E.Message); end; end; end; var fspecZ,fspecP,destDir,se: ansistring; begin fspecZ:='h:\tmp\Dylan.zip'; fspecP:='Dylan.wav'; // this file is 147 MB big destDir:='d:\Tst\unzip\'; // this drive has only 137 MB free se:=unzip_file(fspecZ,fspecP,destDir); writeln('result="', se, '"'); end.
But when I unzip a file, which is bigger than the free space on the destination harddisk, I get no error. The file is just truncated. I would expect to get an error, because the file is invalid.
Do I something wrong?
Is this a bug?
I use FPC 3.0.4 on Windows 7. My little project is attached. Thanks in advance.
I meant there should be a check point method call done in the Tzipper, a method you can call to determine the total unexpanded file size before you actually unzip the file.I have just opened a feature request:
I looked at it, there does not seem to be a way provided to determine required disk space before performing a decompress operation.
Maybe you could suggest an improvement update ? ;)
And what is the difference between:
OLD:
FOutFile.Write(Buf^,Count);
NEW:
FOutFile.WriteBuffer(Buf^,Count);
Raise it an exception now?
@valdir.marcos:I don't think it's necessary since the ticket is already closed.
Thank you very much for creating a bug report in https://bugs.freepascal.org/view.php?id=36068
The bug has been fixed after a few hours.
I have verified the fix and it works.
But I can't add a Note to the bug report nor close it. Maybe I don't have the rights to do this (I am only a "reporter").
Can you add a note and close the report?
Text could be: The fix has been verified by Hartmut with Revision 42985 on Windows 7. Now if the disk is full during unzipping an Exception "Stream write error" is raised. The bug has been fixed. Thanks for fixing.
Hi!Have you already filed a bug report about documentation?
But let us remember that this Zip version works only with the old Zip format < 4 GB.
It will fail with the new version with the maximum of 16 Exabyte.
There should be a notice in the doc file.
Winni
the ticket is already closed.No it is not, it is only "resolved", i.e. the developer solved the issue either by fixing it himself, by apply a patch, or by discarding it. Now it's your turn as reporter to "close" the issue, i.e. you do the final test and verify that the issue really is solved. A "closed" issue is removed from most of the bugtracker lists which helps the developers by thinning out the bug lists. If you don't agree that the issue is solved you can re-open it by clicking on the "Reopen" button (this can happen even after you "closed" the ticket and discover later that the issue still exists under some circumstances.)
Thanks for your information.the ticket is already closed.No it is not, it is only "resolved", i.e. the developer solved the issue either by fixing it himself, by apply a patch, or by discarding it. Now it's your turn as reporter to "close" the issue, i.e. you do the final test and verify that the issue really is solved. A "closed" issue is removed from most of the bugtracker lists which helps the developers by thinning out the bug lists. If you don't agree that the issue is solved you can re-open it by clicking on the "Reopen" button (this can happen even after you "closed" the ticket and discover later that the issue still exists under some circumstances.)
BTW, I would not close this particular issue because it does not consider the argument brought in by sstvmaster (reply #10): The unzipper should check the available disk space *before* beginning to write to disk. The current solution allows to write gigabytes to the HD and notice only at the end that the disk is overrunning. I think Michael was not aware of this aspect when resolving the issue. At least it should be brought to his attention to make him reconsider his solution.I will reopen the ticket and write down all this extra information.
BTW, I would not close this particular issue because it does not consider the argument brought in by sstvmaster (reply #10): The unzipper should check the available disk space *before* beginning to write to disk. The current solution allows to write gigabytes to the HD and notice only at the end that the disk is overrunning. I think Michael was not aware of this aspect when resolving the issue. At least it should be brought to his attention to make him reconsider his solution.I don't agree here. It should be up to the application to decide whether it wants to prohibit extracting to a volume without enough free space or not (e.g. there could be a valid case that one extracts something while deleting something else at the same time).
I don't agree here. It should be up to the application to decide whether it wants to prohibit extracting to a volume without enough free space or notShure, the App could do that.
(e.g. there could be a valid case that one extracts something while deleting something else at the same time).OK, but i never saw something like this.
Not to mention that the SysUtils.DiskFree function might not return something useful on all systems.Then the developer should solve this problem.