First and foremost: thank you for your great work. 7-Zip is my one and only archiver.
In your implementation of CPanel::OnDrag, you're creating a temporary folder to hold the extracted file(s) to be used as source for the drop target. You delete the folder on completion of the drop, but the problem is that drop completion does not necessarily mean that the file(s) were loaded by the target application. One very annoying example is dragging a log file from a .zip file to a Log4View instance. In some cases, the file gets deleted even before Log4View manages to start loading it, and in other cases, it gets a chance to display a preliminary dialog (load configuration), but when the actual loading begins, the file is never there.
The solution is very simple - to delete the temporary folder(s) in the destruction of CPanel, instead of the drop completion. Here's how I did it (and compiled it in VS2015 along the way to make sure it works): Panel.h
I don't want to investigate that problem now.
Are you sure that it's problem of 7-Zip?
Are there any other programs with that problem except of Log4View?
Do other programs (like WinRAR) work OK with Log4View?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes - the problem is a race condition between the deletion of the temp file by 7-Zip, and loading of the file by the target application. WinRAR works OK (probably deletes temporary files on close, or never...).
There's also a similar problem in opening files within the archive by DDE-enabled external applications (e.g. Windows Photo Viewer). Since such applications do not necessarily return a process handle in ShellExecute, 7-Zip is unable to wait for process termination, and deletes the extracted file immediately after calling ShellExecute. This causes the DDE application not to be able to load the file. A classic demonstration for this is to try & open a .jpg file (double-click) from within the archive (if .jpg is associated with Windows Photo Viewer).
It's also relatively simple to fix - in case the process handle is NULL, the CTmpProcessInfoRelease object should be destroyed with the Panel object, instead of being destroyed on the stack as it is today (I have the fixed code if needed).
Alex
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is a case where it's not really clear who's problem it is. You may argue that those DDE calls or COM calls should not return before the application has had a chance to process the file. But that is just not how things have worked out in practice. There is no way to “know” when it's safe to delete the file.
Deleting the files when exiting the app may not be the best approach, but it's the approach most other applications have adopted (including WinZip, WinRar, browsers, FTP clients, etc.), and it usually works. You could consider it a de-facto standard behaviour.
Suppose a program needs a few seconds to process a file when it receives a drop operation. If it would only return after processing, the application sending the drop operation would hang during that time. So the polite thing to do is returning from the drop operation immediately, before processing the file. As it is now, when 7-zip tries to delete that file, it will either succeed and delete the file before the processing is done, or the deletion fails because the file was locked by the program.
Sometimes temporary files will be left behind. That is unavoidable. If the user opens a file, and then closes 7-zip, then it is possible that the application used to open the file has still locked the file. Often the file will be locked until the user closes that file (or saves it under a new file name).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Any update on this? 5 years later the behaviour still hasn't changed, it'd be nice at least to have an option to pick if temp files should be deleted on exit or as soon as possible
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The same happens for me. Simply dragging & dropping files from 7-Zip Manager to the desktop (on Windows 10) fails with an error saying that the temporary files XXX no longer exist. Seems to me that the files get deleted way before the target app is able to process the files (open, read, etc).
Changing "working directory" on the options does nothing to solve this issue.
7-Zip Manager is version 19.00 (x64) as of 2019-02-21. The same happens in 20.00 (alpha) as of 2020-02-06.
Last edit: AndyOlivares 2020-07-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear developer,
First and foremost: thank you for your great work. 7-Zip is my one and only archiver.
In your implementation of CPanel::OnDrag, you're creating a temporary folder to hold the extracted file(s) to be used as source for the drop target. You delete the folder on completion of the drop, but the problem is that drop completion does not necessarily mean that the file(s) were loaded by the target application. One very annoying example is dragging a log file from a .zip file to a Log4View instance. In some cases, the file gets deleted even before Log4View manages to start loading it, and in other cases, it gets a chance to display a preliminary dialog (load configuration), but when the actual loading begins, the file is never there.
The solution is very simple - to delete the temporary folder(s) in the destruction of CPanel, instead of the drop completion. Here's how I did it (and compiled it in VS2015 along the way to make sure it works):
Panel.h
PanelDrag.cpp
Please consider fixing this for the next version.
Thanks!
-Alex
Last edit: Alexander Sharay 2015-11-04
I don't want to investigate that problem now.
Are you sure that it's problem of 7-Zip?
Are there any other programs with that problem except of Log4View?
Do other programs (like WinRAR) work OK with Log4View?
Yes - the problem is a race condition between the deletion of the temp file by 7-Zip, and loading of the file by the target application. WinRAR works OK (probably deletes temporary files on close, or never...).
There's also a similar problem in opening files within the archive by DDE-enabled external applications (e.g. Windows Photo Viewer). Since such applications do not necessarily return a process handle in ShellExecute, 7-Zip is unable to wait for process termination, and deletes the extracted file immediately after calling ShellExecute. This causes the DDE application not to be able to load the file. A classic demonstration for this is to try & open a .jpg file (double-click) from within the archive (if .jpg is associated with Windows Photo Viewer).
It's also relatively simple to fix - in case the process handle is NULL, the CTmpProcessInfoRelease object should be destroyed with the Panel object, instead of being destroyed on the stack as it is today (I have the fixed code if needed).
Alex
This is a case where it's not really clear who's problem it is. You may argue that those DDE calls or COM calls should not return before the application has had a chance to process the file. But that is just not how things have worked out in practice. There is no way to “know” when it's safe to delete the file.
Deleting the files when exiting the app may not be the best approach, but it's the approach most other applications have adopted (including WinZip, WinRar, browsers, FTP clients, etc.), and it usually works. You could consider it a de-facto standard behaviour.
Suppose a program needs a few seconds to process a file when it receives a drop operation. If it would only return after processing, the application sending the drop operation would hang during that time. So the polite thing to do is returning from the drop operation immediately, before processing the file. As it is now, when 7-zip tries to delete that file, it will either succeed and delete the file before the processing is done, or the deletion fails because the file was locked by the program.
Sometimes temporary files will be left behind. That is unavoidable. If the user opens a file, and then closes 7-zip, then it is possible that the application used to open the file has still locked the file. Often the file will be locked until the user closes that file (or saves it under a new file name).
see https://sourceforge.net/p/sevenzip/bugs/1023/
Any update on this? 5 years later the behaviour still hasn't changed, it'd be nice at least to have an option to pick if temp files should be deleted on exit or as soon as possible
The same happens for me. Simply dragging & dropping files from 7-Zip Manager to the desktop (on Windows 10) fails with an error saying that the temporary files XXX no longer exist. Seems to me that the files get deleted way before the target app is able to process the files (open, read, etc).
Changing "working directory" on the options does nothing to solve this issue.
7-Zip Manager is version 19.00 (x64) as of 2019-02-21. The same happens in 20.00 (alpha) as of 2020-02-06.
Last edit: AndyOlivares 2020-07-30