As of 0.7.1, we fetch new data when a user type dir -force for the last node in the current path. For example, \foo\bar\baz.ps1 and dir .\baz.ps1 under foo\bar, bar will be updated. Of course, this behavior will be applied if the provider has attribute: [SHiPSProvider(UseCache=$true)].
If the node bar gets deleted by other tool and dir -force under \foo\bar, a user will get an error saying: Item bar may no longer exists... and SHiPS will remove the node bar from its parent node so that we get the fresh data. This is our desired behavior.
However there is a bug introduced for a case where the following 3 conditions are meet. Under this case, SHiPS thinks the node bar just get deleted. Therefore it removes the node from its cache when a user type dir. This is a bug. SHiPS should not remove it unless a user types dir -force only.
node has no child items
return error
the provider has [SHiPSProvider(UseCache=$true)] attribute
As of 0.7.1, we fetch new data when a user type
dir -force
for the last node in the current path. For example, \foo\bar\baz.ps1 and dir .\baz.ps1 under foo\bar,bar
will be updated. Of course, this behavior will be applied if the provider has attribute:[SHiPSProvider(UseCache=$true)]
.If the node
bar
gets deleted by other tool and dir -force under \foo\bar, a user will get an error saying: Itembar
may no longer exists... and SHiPS will remove the nodebar
from its parent node so that we get the fresh data. This is our desired behavior.However there is a bug introduced for a case where the following 3 conditions are meet. Under this case, SHiPS thinks the node
bar
just get deleted. Therefore it removes the node from its cache when a user typedir
. This is a bug. SHiPS should not remove it unless a user typesdir -force
only.[SHiPSProvider(UseCache=$true)]
attribute