Menu ▾ ▴

#269 FILES EXTRACTED IN 7ZFM LAZILY FAIL TO BE OPENED

open
nobody
None
5
2016-12-12
2004-10-11
Anonymous
No

After the file has been extracted and the associated
application launched by 7-zip File Manager, some times
that application says the file to open is not there
anymore!

Testing 7zFM with Visual Studio debugger, I found
that "DeleteFileAlways" function in FileDir.cpp was called
immediately after the external application has been
started, deleting the temporary file before it could be
opened.

It seems this problem occurs every time the requested
application is a DDE server already active, like WinWord
or Excel: the unique application instance is invoked
by "ShellExecuteEx" (in function "StartApplication" of
PanelItemOpen.cpp) to open the new file, but the
process handle returned in execInfo.hProcess is zero,
since the process was already running. So,
function "OpenItemInArchive" ends immediately, before
creating the external process "control thread" (line 448
in PanelItemOpen.cpp, v. 4.08b), causing the temporary
file to be deleted.
On the contrary, if the external application is quick
enough to open the file, the file itself will no more be
deleted after the application exits, wasting space in
TEMP folder.

I use Windows NT 4.0 (SP6) and have no idea
if "ShellExecuteEx" behaves in a different way on newer
versions of Windows...
I don't know how to derive the process id/handle from
the hInstApp returned by that function call, too!

HOWEWER, adding the SEE_MASK_FLAG_DDEWAIT flag
to the SHELLEXECUTEINFO fMask member helps, since it
suspends code execution until (the DDE conversation
with the application ends and) the file is open. But the
file still remains there after the application is closed...
Note that WinRAR use the same technique *AND* works
fine on my OS!

A simple, complete (but inefficient) solution could be
retrying (or doing) TEMP file deletion on 7zFM closing,
but I refuse to put hands there in!!!

So,what to do? Remember modules invoked
by "ShellExecuteEx" using "FindExecutable" first? Switch
to "CreateProcess" (but it should create a new process
in every case, without reusing the active one)?

Someone solve this, please!!!

Related

Bugs: #1054
Bugs: #1422
Bugs: #1503
Bugs: #269
Bugs: #927

Discussion

  • André Willik Valenti

    André Willik Valenti - 2016-07-06

    I'm considering trying to fix this bug. Any guide on how to contribute to 7zip?

     

  • rice123

    rice123 - 2016-12-12

    Can you please post the patch somewhere, if you've made one? I'd gladly see a fork of 7-zip fixing this annoying long-standing bug.

     

    • André Willik Valenti

      André Willik Valenti - 2016-12-12

      Hello,

      I have not made the changes because I was unable to set up a development
      environment for 7zip. I couldn't find any written guide nor any help, so
      I've given up, unfortunately.

      2016-12-12 16:58 GMT-02:00 rice123 rice123@users.sf.net:

      Can you please post the patch somewhere, if you've made one? I'd gladly
      see a fork of 7-zip fixing this annoying long-standing bug.

      Status: open
      Group:
      Created: Mon Oct 11, 2004 09:44 AM UTC by Anonymous
      Last Updated: Wed Jul 06, 2016 01:38 PM UTC
      Owner: nobody

      After the file has been extracted and the associated
      application launched by 7-zip File Manager, some times
      that application says the file to open is not there
      anymore!

      Testing 7zFM with Visual Studio debugger, I found
      that "DeleteFileAlways" function in FileDir.cpp was called
      immediately after the external application has been
      started, deleting the temporary file before it could be
      opened.

      It seems this problem occurs every time the requested
      application is a DDE server already active, like WinWord
      or Excel: the unique application instance is invoked
      by "ShellExecuteEx" (in function "StartApplication" of
      PanelItemOpen.cpp) to open the new file, but the
      process handle returned in execInfo.hProcess is zero,
      since the process was already running. So,
      function "OpenItemInArchive" ends immediately, before
      creating the external process "control thread" (line 448
      in PanelItemOpen.cpp, v. 4.08b), causing the temporary
      file to be deleted.
      On the contrary, if the external application is quick
      enough to open the file, the file itself will no more be
      deleted after the application exits, wasting space in
      TEMP folder.

      I use Windows NT 4.0 (SP6) and have no idea
      if "ShellExecuteEx" behaves in a different way on newer
      versions of Windows...
      I don't know how to derive the process id/handle from
      the hInstApp returned by that function call, too!

      HOWEWER, adding the SEE_MASK_FLAG_DDEWAIT flag
      to the SHELLEXECUTEINFO fMask member helps, since it
      suspends code execution until (the DDE conversation
      with the application ends and) the file is open. But the
      file still remains there after the application is closed...
      Note that WinRAR use the same technique AND works
      fine on my OS!

      A simple, complete (but inefficient) solution could be
      retrying (or doing) TEMP file deletion on 7zFM closing,
      but I refuse to put hands there in!!!

      So,what to do? Remember modules invoked
      by "ShellExecuteEx" using "FindExecutable" first? Switch
      to "CreateProcess" (but it should create a new process
      in every case, without reusing the active one)?

      Someone solve this, please!!!

      Sent from sourceforge.net because you indicated interest in
      https://sourceforge.net/p/sevenzip/bugs/269/

      To unsubscribe from further messages, please visit
      https://sourceforge.net/auth/subscriptions/

       

      Related

      Bugs: #269

      alternate

      • André Willik Valenti

        André Willik Valenti - 2016-12-12

        In fact, I moved to Bandizip because of this unfixed bug, which is my only
        complaint about 7-zip.

        2016-12-12 17:38 GMT-02:00 "André Willik Valenti" awvalenti@users.sf.net:

        Hello,

        I have not made the changes because I was unable to set up a development
        environment for 7zip. I couldn't find any written guide nor any help, so
        I've given up, unfortunately.

        2016-12-12 16:58 GMT-02:00 rice123 rice123@users.sf.net:

        Can you please post the patch somewhere, if you've made one? I'd gladly
        see a fork of 7-zip fixing this annoying long-standing bug.

        Status: open
        Group:
        Created: Mon Oct 11, 2004 09:44 AM UTC by Anonymous
        Last Updated: Wed Jul 06, 2016 01:38 PM UTC
        Owner: nobody

        After the file has been extracted and the associated
        application launched by 7-zip File Manager, some times
        that application says the file to open is not there
        anymore!

        Testing 7zFM with Visual Studio debugger, I found
        that "DeleteFileAlways" function in FileDir.cpp was called
        immediately after the external application has been
        started, deleting the temporary file before it could be
        opened.

        It seems this problem occurs every time the requested
        application is a DDE server already active, like WinWord
        or Excel: the unique application instance is invoked
        by "ShellExecuteEx" (in function "StartApplication" of
        PanelItemOpen.cpp) to open the new file, but the
        process handle returned in execInfo.hProcess is zero,
        since the process was already running. So,
        function "OpenItemInArchive" ends immediately, before
        creating the external process "control thread" (line 448
        in PanelItemOpen.cpp, v. 4.08b), causing the temporary
        file to be deleted.
        On the contrary, if the external application is quick
        enough to open the file, the file itself will no more be
        deleted after the application exits, wasting space in
        TEMP folder.

        I use Windows NT 4.0 (SP6) and have no idea
        if "ShellExecuteEx" behaves in a different way on newer
        versions of Windows...
        I don't know how to derive the process id/handle from
        the hInstApp returned by that function call, too!

        HOWEWER, adding the SEE_MASK_FLAG_DDEWAIT flag
        to the SHELLEXECUTEINFO fMask member helps, since it
        suspends code execution until (the DDE conversation
        with the application ends and) the file is open. But the
        file still remains there after the application is closed...
        Note that WinRAR use the same technique AND works
        fine on my OS!

        A simple, complete (but inefficient) solution could be
        retrying (or doing) TEMP file deletion on 7zFM closing,
        but I refuse to put hands there in!!!

        So,what to do? Remember modules invoked
        by "ShellExecuteEx" using "FindExecutable" first? Switch
        to "CreateProcess" (but it should create a new process
        in every case, without reusing the active one)?
        Someone solve this, please!!!

        Sent from sourceforge.net because you indicated interest in
        https://sourceforge.net/p/sevenzip/bugs/269/

        To unsubscribe from further messages, please visit
        https://sourceforge.net/auth/subscriptions/

        Status: open
        Group:
        Created: Mon Oct 11, 2004 09:44 AM UTC by Anonymous
        Last Updated: Mon Dec 12, 2016 06:58 PM UTC
        Owner: nobody

        After the file has been extracted and the associated
        application launched by 7-zip File Manager, some times
        that application says the file to open is not there
        anymore!

        Testing 7zFM with Visual Studio debugger, I found
        that "DeleteFileAlways" function in FileDir.cpp was called
        immediately after the external application has been
        started, deleting the temporary file before it could be
        opened.

        It seems this problem occurs every time the requested
        application is a DDE server already active, like WinWord
        or Excel: the unique application instance is invoked
        by "ShellExecuteEx" (in function "StartApplication" of
        PanelItemOpen.cpp) to open the new file, but the
        process handle returned in execInfo.hProcess is zero,
        since the process was already running. So,
        function "OpenItemInArchive" ends immediately, before
        creating the external process "control thread" (line 448
        in PanelItemOpen.cpp, v. 4.08b), causing the temporary
        file to be deleted.
        On the contrary, if the external application is quick
        enough to open the file, the file itself will no more be
        deleted after the application exits, wasting space in
        TEMP folder.

        I use Windows NT 4.0 (SP6) and have no idea
        if "ShellExecuteEx" behaves in a different way on newer
        versions of Windows...
        I don't know how to derive the process id/handle from
        the hInstApp returned by that function call, too!

        HOWEWER, adding the SEE_MASK_FLAG_DDEWAIT flag
        to the SHELLEXECUTEINFO fMask member helps, since it
        suspends code execution until (the DDE conversation
        with the application ends and) the file is open. But the
        file still remains there after the application is closed...
        Note that WinRAR use the same technique AND works
        fine on my OS!

        A simple, complete (but inefficient) solution could be
        retrying (or doing) TEMP file deletion on 7zFM closing,
        but I refuse to put hands there in!!!

        So,what to do? Remember modules invoked
        by "ShellExecuteEx" using "FindExecutable" first? Switch
        to "CreateProcess" (but it should create a new process
        in every case, without reusing the active one)?

        Someone solve this, please!!!

        Sent from sourceforge.net because you indicated interest in
        https://sourceforge.net/p/sevenzip/bugs/269/

        To unsubscribe from further messages, please visit
        https://sourceforge.net/auth/subscriptions/

         

        Related

        Bugs: #269

Log in to post a comment.

MongoDB Logo MongoDB