In 7-zip file manager, double-click a picture in a 7z (or zip ,rar ) file, windows photo viewer can't show it with message “windows photo viewer can't open this picture because either the picture is deleted or it's in a location that isn't available”. The OS is Win7. and the same operation in winrar is OK. So, anybody knows why?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The Program1 (some photo file handler) calls another Program2 (windows photo viewer) and closes Program1.
But 7-Zip waits only Program1. So it deletes image from temp folder.
I plan to fix that problem in future.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With version 9.20 x64 on Windows 7 64bit, the windows photo viewer stays forever with message "Loading…" (translated from italian), and no pictures is displayed.
Thank You.
Matteo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This bug is really annoying.
I wanted to know if there is a chance to resolve it because from what I see does not seem to be resolved.
I tried both the stable 64-bit and 64-bit alpha and the problem is still there.
7-zip is a really good software, but this annoying bug bothers me a lot.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In fact if I use XnView images are opened and they see no problems!
And you could set an option where if you leave the default viewer or set another?
So I could use the normal windows picture viewer and when I open the archives to see the photos I'd use what I set in the options.
In options there is a tab editor, but I do not think serves this purpose.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have encoutered with "windows photo viewer can't open this picture because either the picture is deleted, or it's in a location that isn't available" when tried to open .jpg from zip file (.zip) as well.
I solved it with easy way by open 7-Zip File Manager -> Tools -> Options -> uncheck in zip check box
Good luck.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is maybe some extra help for you Igor? Can you retry to fix this problem? I try to open GBR.jpg from a zip file. This is sysinternals filemon log. I see that 7zFM.exe is deleting the file first and then the temp folder. See below.
20:36:53 7zFM.exe:2756 OPEN C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp\GBR.jpg SUCCESS Options: Open Access: All
20:36:53 7zFM.exe:2756 OPEN C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp\ SUCCESS Options: Open Directory Access: All
20:36:53 7zFM.exe:2756 SET INFORMATION C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp\GBR.jpg SUCCESS FileBasicInformation
20:36:53 7zFM.exe:2756 CLOSE C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp\GBR.jpg SUCCESS
20:36:53 7zFM.exe:2756 OPEN C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp\GBR.jpg SUCCESS Options: Open Access: All
20:36:53 7zFM.exe:2756 OPEN C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp\ SUCCESS Options: Open Directory Access: All
20:36:53 7zFM.exe:2756 QUERY INFORMATION C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp\GBR.jpg SUCCESS FileAttributeTagInformation 20:36:53 7zFM.exe:2756 DELETE C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp\GBR.jpg SUCCESS
20:36:53 7zFM.exe:2756 CLOSE C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp\GBR.jpg SUCCESS
20:36:53 7zFM.exe:2756 OPEN C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp SUCCESS Options: Open Directory Access: All
20:36:53 7zFM.exe:2756 OPEN C:\Users\ADMINI~1\AppData\Local\Temp\ SUCCESS Options: Open Directory Access: All
20:36:53 7zFM.exe:2756 QUERY INFORMATION C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp SUCCESS FileAttributeTagInformation 20:36:53 7zFM.exe:2756 DELETE C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp SUCCESS
20:36:53 7zFM.exe:2756 CLOSE C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp SUCCESS
20:36:53 7zFM.exe:2756 OPEN C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp\ NOT FOUND Options: Open Directory Access: All
20:36:53 7zFM.exe:2756 OPEN C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp\ NOT FOUND Options: Open Directory Access: All
20:36:53 7zFM.exe:2756 OPEN C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp NOT FOUND Options: Open Access: All
20:36:53 7zFM.exe:2756 OPEN C:\Users\ADMINI~1\AppData\Local\Temp\ SUCCESS Options: Open Directory Access: All
20:36:53 7zFM.exe:2756 OPEN C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp NOT FOUND Options: Open Access: All
20:36:53 7zFM.exe:2756 OPEN C:\Users\ADMINI~1\AppData\Local\Temp\ SUCCESS Options: Open Directory Access: All
20:36:53 explorer.exe:2512 DIRECTORY C:\Users\Administrator\AppData\Local\Temp Change Notify
20:36:53 dllhost.exe:2260 OPEN C:\Windows\system32\actxprxy.dll SUCCESS Options: Open Access: All
20:36:53 dllhost.exe:2260 QUERY INFORMATION C:\Windows\system32\actxprxy.dll SUCCESS Attributes: A
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just spent the past 15 minutes having to explain to my wife (who is NOT computer savvy) that the 13MB zip file of images we e-mailed to someone was in fact perfectly fine and NOT corrupted.
The problem is that every single time we opened a photo from the zip file, 7-Zip would unzip the file, launch Windows Photo Viewer, and then proceed to delete the file -- and directory -- out from under Windows Photo Viewer.
The problem is that Windows Photo Viewer handles that case by not showing the image in question; in fact, in Windows 8.1, the most you get is it forever saying "Loading..." because they account for the fact that users will delete photos from Explorer. (NOTE: I have not tried the "Metro" viewer, but I assume that unless it locks the file, it will do the same thing.)
As for "use another viewer", I strongly believe that 7-Zip's long-term adoption rate will be severely hindered if it doesn't play nice with the default photo viewer in the OS.
I would seriously consider one of the following options:
1. Unzip it to %TEMP% and forget it
2. Don't delete it until the 7-Zip process is closed.
3. Use a file system watcher (the APIs that implement System.IO.FileSystemWatcher in .NET -- I don't know the exact APIs, but I know it's not .NET-specific).
Thanks,
# Chris
EDIT: one of these days I'll remember to preview before posting and not see my signature as an h1 tag.
I think this is not a bug, it's a design flaw.
The current procedure seems to be as follows:
- unzip the selected files to TEMP
- detach the viewer process, passing the file names as parameters
- wait for the viewer process to terminate and then delete the files from TEMP
So the objectives:
- to keep TEMP as clean as possible
- to minimize the communication overhead
are met, but this procedure fails, if the "viewer" process is only an intermediate process (as it is in Windows Previewer) and starts a new process with the "real" viewer und terminates itsself.
So 7-zip supposes that the viewer process has terminated and cleans up TEMP and the "real" viewer has no more files available.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A possible solution (Windows XP or later) is:
- create a Job object
- create the viewer process in suspended state and assign it to the Job object
- let the viewer process run
- wait for the Job object to terminate
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, programs for which this approach will work have more or less gone extinct. Double-clicking a file pretty much never works, for any file type.
Most programs use a MDI (i.e. tabs), and often the process to open the file will run for only a fraction of a second, to simply send a message to another process.
The same goes for drag'n'drop. A well-written program will register the dropped file message, but process it asynchronously. This will avoid hanging the process where the drag operation originated. But in case of 7-zip, by the time the destination program tries to open the file, the temporary file is gone.
Most other programs solve this by deleting the temporary files only on exiting the application.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'd like to add, 7-zip is my favourite archiving program.
But this bug means I can't recommend it to most people. For 90% of the computer users out there, 7-zip is simply broken. The average computer user doesn't care about the internals of temporary files and COM or DDE, or single-instance MDI programs (and they shouldn't have to). They observe double-clicking an image in WinRAR or WinZip will work, and double-clicking an image in 7-zip will just show a weird error message.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That problem is difficult to fix. Big changes are required.
It's in plans, but I'll try to do it, when some another things (that are more simple) will be implemented.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Are you freakin' kidding me? This design flaw has persisted for at least FIVE YEARS and you remain uncommited to fixing it? Wow. This is NOT a hard issue to fix, please, get on it asap and get it done, this is a major usability issue (no, I do NOT wish to google me up an alternate image viewer when windows has a perfectly good one already installed)!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Bab Zog, did you donate to the project / the author ?
If yes, then you are crude and impolite.
If no, you just miss the idea of opensource software: either you support it financially, either by doing a user support or you do it technically. And you chose to do neither of which, it seems at the first glance.
Last edit: Saulius Krasuckas 2016-02-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
But thanks to whoever mention xnview. I didnt know i need another viewer, lol, but its quite handy as it can resize with the mousewheel. Love that feature
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In 7-zip file manager, double-click a picture in a 7z (or zip ,rar ) file, windows photo viewer can't show it with message “windows photo viewer can't open this picture because either the picture is deleted or it's in a location that isn't available”. The OS is Win7. and the same operation in winrar is OK. So, anybody knows why?
The Program1 (some photo file handler) calls another Program2 (windows photo viewer) and closes Program1.
But 7-Zip waits only Program1. So it deletes image from temp folder.
I plan to fix that problem in future.
Thanks a lot。
Hi,
Is there any ETA for this to be fixed?
Thanks & Regards
Hallo.
With version 9.20 x64 on Windows 7 64bit, the windows photo viewer stays forever with message "Loading…" (translated from italian), and no pictures is displayed.
Thank You.
Matteo
is this supposed to be fixed yet? i'm still seeing this issue on win7-x64.
couldn't the problem be fixed by waiting a few seconds before attempting the delete?
This bug is really annoying.
I wanted to know if there is a chance to resolve it because from what I see does not seem to be resolved.
I tried both the stable 64-bit and 64-bit alpha and the problem is still there.
7-zip is a really good software, but this annoying bug bothers me a lot.
I don't see simple ways to fix it now.
You can use another viewer for jpg files.
In fact if I use XnView images are opened and they see no problems!
And you could set an option where if you leave the default viewer or set another?
So I could use the normal windows picture viewer and when I open the archives to see the photos I'd use what I set in the options.
In options there is a tab editor, but I do not think serves this purpose.
Hi.
I have encoutered with "windows photo viewer can't open this picture because either the picture is deleted, or it's in a location that isn't available" when tried to open .jpg from zip file (.zip) as well.
I solved it with easy way by open 7-Zip File Manager -> Tools -> Options -> uncheck in zip check box
Good luck.
This is maybe some extra help for you Igor? Can you retry to fix this problem? I try to open GBR.jpg from a zip file. This is sysinternals filemon log. I see that 7zFM.exe is deleting the file first and then the temp folder. See below.
20:36:53 7zFM.exe:2756 OPEN C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp\GBR.jpg SUCCESS Options: Open Access: All
20:36:53 7zFM.exe:2756 OPEN C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp\ SUCCESS Options: Open Directory Access: All
20:36:53 7zFM.exe:2756 SET INFORMATION C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp\GBR.jpg SUCCESS FileBasicInformation
20:36:53 7zFM.exe:2756 CLOSE C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp\GBR.jpg SUCCESS
20:36:53 7zFM.exe:2756 OPEN C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp\GBR.jpg SUCCESS Options: Open Access: All
20:36:53 7zFM.exe:2756 OPEN C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp\ SUCCESS Options: Open Directory Access: All
20:36:53 7zFM.exe:2756 QUERY INFORMATION C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp\GBR.jpg SUCCESS FileAttributeTagInformation
20:36:53 7zFM.exe:2756 DELETE C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp\GBR.jpg SUCCESS
20:36:53 7zFM.exe:2756 CLOSE C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp\GBR.jpg SUCCESS
20:36:53 7zFM.exe:2756 OPEN C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp SUCCESS Options: Open Directory Access: All
20:36:53 7zFM.exe:2756 OPEN C:\Users\ADMINI~1\AppData\Local\Temp\ SUCCESS Options: Open Directory Access: All
20:36:53 7zFM.exe:2756 QUERY INFORMATION C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp SUCCESS FileAttributeTagInformation
20:36:53 7zFM.exe:2756 DELETE C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp SUCCESS
20:36:53 7zFM.exe:2756 CLOSE C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp SUCCESS
20:36:53 7zFM.exe:2756 OPEN C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp\ NOT FOUND Options: Open Directory Access: All
20:36:53 7zFM.exe:2756 OPEN C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp\ NOT FOUND Options: Open Directory Access: All
20:36:53 7zFM.exe:2756 OPEN C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp NOT FOUND Options: Open Access: All
20:36:53 7zFM.exe:2756 OPEN C:\Users\ADMINI~1\AppData\Local\Temp\ SUCCESS Options: Open Directory Access: All
20:36:53 7zFM.exe:2756 OPEN C:\Users\ADMINI~1\AppData\Local\Temp\7zO86BA.tmp NOT FOUND Options: Open Access: All
20:36:53 7zFM.exe:2756 OPEN C:\Users\ADMINI~1\AppData\Local\Temp\ SUCCESS Options: Open Directory Access: All
20:36:53 explorer.exe:2512 DIRECTORY C:\Users\Administrator\AppData\Local\Temp Change Notify
20:36:53 dllhost.exe:2260 OPEN C:\Windows\system32\actxprxy.dll SUCCESS Options: Open Access: All
20:36:53 dllhost.exe:2260 QUERY INFORMATION C:\Windows\system32\actxprxy.dll SUCCESS Attributes: A
I strongly urge you to consider fixing this bug.
I just spent the past 15 minutes having to explain to my wife (who is NOT computer savvy) that the 13MB zip file of images we e-mailed to someone was in fact perfectly fine and NOT corrupted.
The problem is that every single time we opened a photo from the zip file, 7-Zip would unzip the file, launch Windows Photo Viewer, and then proceed to delete the file -- and directory -- out from under Windows Photo Viewer.
The problem is that Windows Photo Viewer handles that case by not showing the image in question; in fact, in Windows 8.1, the most you get is it forever saying "Loading..." because they account for the fact that users will delete photos from Explorer. (NOTE: I have not tried the "Metro" viewer, but I assume that unless it locks the file, it will do the same thing.)
As for "use another viewer", I strongly believe that 7-Zip's long-term adoption rate will be severely hindered if it doesn't play nice with the default photo viewer in the OS.
I would seriously consider one of the following options:
1. Unzip it to %TEMP% and forget it
2. Don't delete it until the 7-Zip process is closed.
3. Use a file system watcher (the APIs that implement System.IO.FileSystemWatcher in .NET -- I don't know the exact APIs, but I know it's not .NET-specific).
Thanks,
# Chris
EDIT: one of these days I'll remember to preview before posting and not see my signature as an h1 tag.
Last edit: Chris Donnelly 2014-01-27
I think this is not a bug, it's a design flaw.
The current procedure seems to be as follows:
- unzip the selected files to TEMP
- detach the viewer process, passing the file names as parameters
- wait for the viewer process to terminate and then delete the files from TEMP
So the objectives:
- to keep TEMP as clean as possible
- to minimize the communication overhead
are met, but this procedure fails, if the "viewer" process is only an intermediate process (as it is in Windows Previewer) and starts a new process with the "real" viewer und terminates itsself.
So 7-zip supposes that the viewer process has terminated and cleans up TEMP and the "real" viewer has no more files available.
A possible solution (Windows XP or later) is:
- create a Job object
- create the viewer process in suspended state and assign it to the Job object
- let the viewer process run
- wait for the Job object to terminate
Can we have hope that this problem would be fixed?
Some user prefer don't install alternative image viewer and use Image View of Windows.
THANK YOU VERY MUCH IF YOU CAN FIX
Yes, programs for which this approach will work have more or less gone extinct. Double-clicking a file pretty much never works, for any file type.
Most programs use a MDI (i.e. tabs), and often the process to open the file will run for only a fraction of a second, to simply send a message to another process.
The same goes for drag'n'drop. A well-written program will register the dropped file message, but process it asynchronously. This will avoid hanging the process where the drag operation originated. But in case of 7-zip, by the time the destination program tries to open the file, the temporary file is gone.
Most other programs solve this by deleting the temporary files only on exiting the application.
I'd like to add, 7-zip is my favourite archiving program.
But this bug means I can't recommend it to most people. For 90% of the computer users out there, 7-zip is simply broken. The average computer user doesn't care about the internals of temporary files and COM or DDE, or single-instance MDI programs (and they shouldn't have to). They observe double-clicking an image in WinRAR or WinZip will work, and double-clicking an image in 7-zip will just show a weird error message.
This problem still not correct in last version of 7Zip.
Igor, please can you change this design flaw ?
thx
That problem is difficult to fix. Big changes are required.
It's in plans, but I'll try to do it, when some another things (that are more simple) will be implemented.
Igor, thanks for keeping us informed.
Do you accept patches / collaboration from other people?
Igor, thanks for keeping us informed.
Do you accept patches / collaboration from other people?
Are you freakin' kidding me? This design flaw has persisted for at least FIVE YEARS and you remain uncommited to fixing it? Wow. This is NOT a hard issue to fix, please, get on it asap and get it done, this is a major usability issue (no, I do NOT wish to google me up an alternate image viewer when windows has a perfectly good one already installed)!
Bab Zog, did you donate to the project / the author ?
If yes, then you are crude and impolite.
If no, you just miss the idea of opensource software: either you support it financially, either by doing a user support or you do it technically. And you chose to do neither of which, it seems at the first glance.
Last edit: Saulius Krasuckas 2016-02-02
pictures preview works, at least for jpg bmp and dds.
no they don't
But thanks to whoever mention xnview. I didnt know i need another viewer, lol, but its quite handy as it can resize with the mousewheel. Love that feature