none
How can I see Process being executed? RRS feed

  • Question

  • I have a loop that is supposed to zip every folder in a particular location. It works exactly once. The second time through the loop, no zip file is created. My output window reports only "Error: No such archive". Stepping through the code, the "foundDir" is correct, so the Shell Command being executed must be bad, but I can't see the command it was trying to execute.

    Here is my code. It invisibly executes "7za.exe" (the 7zip archiver CLI) with arguments and "foundDir" name, and sends the screen output to a textbox:

    Dim oProcess As New Process()
    Dim oStartInfo As New ProcessStartInfo(strSrcPath & "7za.exe", "-?") ' "-?" argument shown here is simply so I know it supports switches.
    oStartInfo.UseShellExecute = False
    oStartInfo.RedirectStandardOutput = True
    oProcess.StartInfo = oStartInfo
    Dim sOutput As String
    
    For Each foundDir In My.Computer.FileSystem.GetDirectories(strSrcPath & "\Plugins\")
        ' Check for existence of zip file at target. If it exists, prompt for overwrite. If not, skip.
        bolSkip = False ' reset
        strSource = foundDir.Substring(InStrRev(foundDir, "\")) ' Get just the foldername from the end of the path.
        strCompletedZip = txtPrefix.Text & strSource & ".zip" ' Optional "Prefix" entered by user.
        If My.Computer.FileSystem.FileExists(strDestPath & "\" & txtPrefix.Text & strSource & "\Plugins\" & strSource & ".zip") = True Then
            Dim response = MsgBox("Target '" & strSource & ".zip' already exists!" & vbCrLf & vbCrLf & "Overwrite?", MsgBoxStyle.YesNo)
            If response = MsgBoxResult.No Then bolSkip = True
        End If
        If Not bolSkip Then   ' Compress & move.
            txtOutput.Text = ""     ' Clear output window.
            oStartInfo.Arguments = "a -tzip " & foundDir
            oProcess.Start()
            Using oStreamReader As System.IO.StreamReader = oProcess.StandardOutput
               sOutput = oStreamReader.ReadToEnd()
               txtOutput.AppendText(sOutput & vbCrLf) ' Append output w/o reassigning/printing the entire contents over & over. "Append" forces window to scroll.
            End Using
            My.Computer.FileSystem.MoveFile(foundDir & ".zip", strDestPath & "\" & txtPrefix.Text & strSource & "\Plugins\" & strSource & ".zip", True)
            ' Delete source folder after compressing.
            My.Computer.FileSystem.DeleteDirectory(foundDir, FileIO.DeleteDirectoryOption.DeleteAllContents)
        End If
    Next

    First time through the loop, it correctly finds the first folder, compresses it, then moves it to a location specified by the user. Second time through the loop, it sees the next folder, but when it executes "oProcess.Start()", no zip file is created and I have no idea why. I need to see the command being executed (if any) but I can't figure out how.

    Any help is appreciated. TIA.


    Thursday, December 27, 2018 9:56 PM

All replies

  • Hi

    I would suggest that you place a BreakPoint on the Process.Start line and examine the values that are being used and if they are as expected.


    Regards Les, Livingston, Scotland

    Thursday, December 27, 2018 10:05 PM
  • Hi

    I would suggest that you place a BreakPoint on the Process.Start line and examine the values that are being used and if they are as expected.


    Thanks, but I've single-stepped through the code and can't see what "oProcess.Start()" is. It merely says:

    "oProcess | System.Diagnostics.Process" every time (including the first time .)

    Thursday, December 27, 2018 10:23 PM
  • Hi

    I would suggest that you place a BreakPoint on the Process.Start line and examine the values that are being used and if they are as expected.


    Thanks, but I've single-stepped through the code and can't see what "oProcess.Start()" is. It merely says:

    "oProcess | System.Diagnostics.Process" every time (including the first time .)

    Hi

    When it stops at that line, hover the mouse over the '

    foundDir

    variable and see if it is as expected.


    Regards Les, Livingston, Scotland

    Thursday, December 27, 2018 10:32 PM
  • When it stops at that line, hover the mouse over the '
    foundDir

    variable and see if it is as expected.


    Yes, as reported in my question, the foundDir is correct every time. The problem lies in the command being (or not being) executed.

    Thursday, December 27, 2018 10:53 PM
  • When it stops at that line, hover the mouse over the '
    foundDir

    variable and see if it is as expected.


    Yes, as reported in my question, the foundDir is correct every time. The problem lies in the command being (or not being) executed.

    Hi

    OK, a recap. When run, your code reaches the Process.Start line every time it should, with the correct arguments but fails to execute the Process.Start at all? - sorry., exccept for the first time where it runs correctly.

    The only thing I can come up with now is that the Process is busy and can't be interupted by a new call to it.

    To test that idea, put a Stop command directly after the Process.Start line and run your code - each time it reaches the Stop, click continue and see it each file is processed.

    If it is, then the next approach could be to start each Process on its own thread - but that is another subject.


    Regards Les, Livingston, Scotland

    Thursday, December 27, 2018 11:12 PM
  • OK, a recap. When run, your code reaches the Process.Start line every time it should, with the correct arguments but fails to execute the Process.Start at all? - sorry., exccept for the first time where it runs correctly.

    The only thing I can come up with now is that the Process is busy and can't be interupted by a new call to it.

    To test that idea, put a Stop command directly after the Process.Start line


    That makes sense. There is no ".Stop" method, but I added a ".Close" method after the last use of "oStreamReader". Unfortunately, that didn't fix the problem.

    But further testing seems to reveal something else is going on. As I mentioned, after zipping the first folder ("!Freeze_AC0_AP0_KS1"), no other folders are compressed. So I deleted that first folder to see if it would zip the next one (now first, named "0.Filters") but it was STILL ignored.

    So I deleted THAT folder and went onto the next one (also oddly named), which also failed.

    I then deleted every folder and created folders "Test001" thru "Test009", and the problem went away. So, the problem appears to be "oddly named folders." I don't know why. I can zip the folders manually using "7za.exe", but not from my program.

    I'm going to try another archiver capable of ".zip" to see if it has the same problem. I'd prefer not to use Windows' built-in zip because it's slow, provides poor compression (and there are still a few XP users out there with no built-in zip support.)

    I'll report back if I find a solution. Thanks.

    (Solved? - It appears the problem occurs with any folder name that contains a decimal in the name. Now I just need to figure out why.)
    Friday, December 28, 2018 2:21 PM
  • Here is some of your code with some changes.  The big change is moving the process creation inside the for loop.  You'll have to add the pieces I left out

            strSrcPath = IO.Path.Combine(strSrcPath, "Plugins")
            Dim dirsToComp() As String = IO.Directory.GetDirectories(strSrcPath)
    
            For Each foundDir As String In dirsToComp
                bolSkip = False ' reset
                ' IO.Path.GetFileName returns the characters after the last directory character in path
                '  this means if you have a list of folders then you are actually getting the directory name
                strSource = IO.Path.GetFileName(foundDir) ' Get just the foldername from the end of the path.
    
                '
                ' your code
                '
                If Not bolSkip Then
                    Dim oProcess As New Process()
                    Dim oStartInfo As New ProcessStartInfo(strSrcPath & "7za.exe", "-?") ' "-?" argument shown here is simply so I know it supports switches.
                    oStartInfo.UseShellExecute = False
                    oStartInfo.RedirectStandardOutput = True
                    oProcess.StartInfo = oStartInfo
                    Dim sOutput As String
    
                    oStartInfo.Arguments = "a -tzip " & foundDir
                    oProcess.Start()
                    Using oStreamReader As System.IO.StreamReader = oProcess.StandardOutput
    
                    End Using
    
                    oProcess.WaitForExit()
                    oProcess.Dispose()
                End If
            Next
    


    "Those who use Application.DoEvents() have no idea what it does and those who know what it does never use it."

    - from former MSDN User JohnWein

    SerialPort Info

    Multics - An OS ahead of its time.

    Friday, December 28, 2018 3:01 PM
  • Here is some of your code with some changes.  The big change is moving the process creation inside the for loop.  You'll have to add the pieces I left out.

    .
    Thanks for the follow-up. Those are some good changes though it didn't solve the issue (which I'm fairly certain now lies with "7za.exe" and not my code. When I tested "manually" compressing folders, I didn't try folders with a "decimal" in the name. I tried again and it resulted in an error, confirming the fault lies with "7za.exe".)

    I tried a newer version of 7Zip but it still has the bug. So I'm now looking for a replacement. I need something I can redirect the Console output to a textbox.

    I should have used your method to get the foldername (I replaced my code with yours) in the first place but forgot about the function.

    Thanks for the info.

    Friday, December 28, 2018 4:10 PM
  • Have you considered using the built in ZipFile Class?

    Search Documentation

    SerialPort Info

    Multics - An OS ahead of its time.

     "Those who use Application.DoEvents have no idea what it does

        and those who know what it does never use it."    former MSDN User JohnWein

    Friday, December 28, 2018 4:24 PM
  • Have you considered using the built in ZipFile Class?

    .
    Yes, and I'd like to, but I can't figure out how to output the compression-progress to a textbox/console.

    AFAICT, the built-in Zip doesn't display any progress while working. :(

    Friday, December 28, 2018 5:18 PM
  • Have you considered using the built in ZipFile Class?

    .
    Yes, and I'd like to, but I can't figure out how to output the compression-progress to a textbox/console.

    AFAICT, the built-in Zip doesn't display any progress while working. :(


    How long are we taking to compress a folder?  You could spin the Zip off into a Task and then report the archive size as an indication that something is occurring.

    Search Documentation

    SerialPort Info

    Multics - An OS ahead of its time.

     "Those who use Application.DoEvents have no idea what it does

        and those who know what it does never use it."    former MSDN User JohnWein

    Friday, December 28, 2018 5:52 PM
  • How long are we taking to compress a folder?  You could spin the Zip off into a Task and then report the archive size as an indication that something is occurring.

    .
    Thanks for the idea, but I wish to give users a sense of "time remaining" rather than simply showing "activity".

    My utility is going through a folder that can contain hundreds of folders for archiving. Users could easily spend over an hour waiting on the program to finish (depending on number of folders & computer speed.) It would be nice if they had some sense of progress while working. :)
    Friday, December 28, 2018 6:04 PM
  • How long are we taking to compress a folder?  You could spin the Zip off into a Task and then report the archive size as an indication that something is occurring.

    .
    Thanks for the idea, but I wish to give users a sense of "time remaining" rather than simply showing "activity".

    My utility is going through a folder that can contain hundreds of folders for archiving. Users could easily spend over an hour waiting on the program to finish (depending on number of folders & computer speed.) It would be nice if they had some sense of progress while working. :)

    How about making a progress bar that represent the number of folders, increment as you go, with a label showing size of archive? 

    Search Documentation

    SerialPort Info

    Multics - An OS ahead of its time.

     "Those who use Application.DoEvents have no idea what it does

        and those who know what it does never use it."    former MSDN User JohnWein

    Friday, December 28, 2018 6:25 PM
  • How about making a progress bar that represent the number of folders, increment as you go,

    .
    That's an interesting idea too, but that only gives you a meter for the total process.

    You still have the problem of not having any sense of how long each folder is taking to compress.

    If I can't find an alternative, I may still try that.

    Thanks.

    Friday, December 28, 2018 6:32 PM