Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Losing jumpstat data, when working from multiply powershell windows #37

Open
vors opened this issue Sep 26, 2014 · 11 comments
Open

Losing jumpstat data, when working from multiply powershell windows #37

vors opened this issue Sep 26, 2014 · 11 comments
Labels

Comments

@vors
Copy link
Collaborator

vors commented Sep 26, 2014

I called jumpstat sequentially and data is not consistent: it's wiped at some point.
Should be a problem with DB -> file save logic

image

@vors
Copy link
Collaborator Author

vors commented Sep 26, 2014

Cannot repro it anymore

@vors vors added the bug label Sep 26, 2014
@vors vors changed the title Losing jumpstat data in 0.6.0 release candidate Losing jumpstat data Sep 26, 2014
@vors
Copy link
Collaborator Author

vors commented Sep 28, 2014

Repro:

  1. Open 3 powershell windows with Jump-Location module loaded.
  2. Create folder "trololo" and cd to it
  3. Call "jumpstat trololo" many times.

Expected:
Results are consistent: weight increases every time

Actual:
Sometimes you get empty set.

@vors vors changed the title Losing jumpstat data Losing jumpstat data, when working from multiply powershell windows Sep 28, 2014
@pvandervelde
Copy link

I'm wondering if I'm seeing the same thing. I have multiple powershell windows open all the time and my jumplist only ever contains one item (C:\users\Patrick.VanDerVelde which is my user directory from which powershell starts). I don't normally spend any time in that directory but navigate away to my GIT repo directories and stay there but they never show up. Could that be due to this issue or is it maybe another issue?

@vors
Copy link
Collaborator Author

vors commented Oct 13, 2014

If you don't have any PS windows open in this directory, it's probably something different. Update logic is not very robust, unfortunately.
Are you using version 0.6.0? You can troubleshoot some problems with
Get-Job | fl
You should get background job which is responsible for call UpdateTime callback. If status of this Job is not Running, something went wrong.

@pvandervelde
Copy link

Running 0.6.0 based on my module list:

C:\Users\Patrick.VanDerVelde> Get-Module

ModuleType Version Name ExportedCommands


Binary 0.6.0.0 Jump.Location {Get-JumpStatus, Set-JumpLocation}
Script 0.6.0 Jump.Location
Manifest 3.1.0.0 Microsoft.PowerShell.Management {Add-Computer, Add-Content, Checkpoint-Computer, Clear-Content...}
Manifest 3.1.0.0 Microsoft.PowerShell.Utility {Add-Member, Add-Type, Clear-Variable, Compare-Object...}
Script 0.0 posh-git {Add-SshKey, Enable-GitColors, Get-AliasPattern, Get-GitDirectory...}
Script 1.0.0.12 PSReadLine {Get-PSReadlineKeyHandler, Get-PSReadlineOption, Set-PSReadlineKeyHandler, Set-PSReadlineOpt...
Binary 1.1.0.0 PSScheduledJob {Add-JobTrigger, Disable-JobTrigger, Disable-ScheduledJob, Enable-JobTrigger...}
Manifest 2.0.0.0 PSWorkflow {New-PSWorkflowExecutionOption, New-PSWorkflowSession, nwsn}

Looking at the job list it seems that the job is there in one of my windows

C:\Users\Patrick.VanDerVelde> get-Job | fl

Module : __DynamicModule_3ac53c16-7d67-4e73-add2-02c45bf0a477
StatusMessage :
HasMoreData : True
Location :
Command :
[Jump.Location.SetJumpLocationCommand]::UpdateTime($($(Get-Item -Path $(Get-Location))).PSPath)

JobStateInfo : Running
Finished : System.Threading.ManualResetEvent
InstanceId : efb9201a-2749-4a6d-a467-0f07d2acedbe
Id : 1
Name : PowerShell.OnIdle
ChildJobs : {}
PSBeginTime : 13/10/2014 13:58:50
PSEndTime :
PSJobTypeName :
Output : {}
Error : {}
Progress : {}
Verbose : {}
Debug : {}
Warning : {}
State : Running

In the other window I get this:

C:\vcs\git\devinfrastructure\Scripts [master +10 ~0 -0 !]> get-Job | fl

Module : __DynamicModule_79e2e61d-d974-4772-bb70-1062c2005f29
StatusMessage :
HasMoreData : False
Location :
Command :
[Jump.Location.SetJumpLocationCommand]::UpdateTime($($(Get-Item -Path $(Get-Location))).PSPath)

JobStateInfo : NotStarted
Finished : System.Threading.ManualResetEvent
InstanceId : fa84f162-c3d2-435e-9c5a-41e0a7bf5f31
Id : 1
Name : PowerShell.OnIdle
ChildJobs : {}
PSBeginTime :
PSEndTime :
PSJobTypeName :
Output : {}
Error : {}
Progress : {}
Verbose : {}
Debug : {}
Warning : {}
State : NotStarted

Creating another window and running Get-Job again indicates that this last output is from the second window I started.

Shutting down all powershell windows (including ISE) and then starting a new window still doesn't start the job. Currently can't be bothered rebooting the machine to test further.

@vors
Copy link
Collaborator Author

vors commented Oct 14, 2014

I see similar results. In fact, if I run powershell.exe, JobStateInfo is always NotStarted. When I use powershell_ise.exe (which I usually use), Job is Running.

@vors
Copy link
Collaborator Author

vors commented Oct 14, 2014

Looks like it relate to interaction between Jump-Location and PSReadLine. Everything works fine, if I disable PSReadLine. @pvandervelde do you use it?

@vors
Copy link
Collaborator Author

vors commented Oct 14, 2014

I opened #56 to track problem with PSReadLine. @pvandervelde let me know, if it's something different for you.

@pvandervelde
Copy link

Yeah I have that module loaded as well!

@vors
Copy link
Collaborator Author

vors commented Oct 14, 2014

@pvandervelde as a work-around you can pre-populate jump location DB in powershell session without PSReadLine (i.e. powershell_ise.exe). Then you will be able to use it with PSReadLine, but no new info will be added.

@anthony-brien
Copy link

Same issue when I run powershell in both VSCode and Cmder. When I use jump-location in either, it wipes the stats accumulated from the other shell.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants