Why is my PowerShell script writing blank lines to console? - powershell

I have a bit of an odd problem. Or maybe not so odd. I had to implement a "custom clean" for a PowerShell script developed for building some unique configurations for my current project (the whys are not particularly important). Basically it copies a bunch of files from the release directories into some temporary directories with this code:
$Paths = Get-ChildItem $ProjectPath -recurse |
Where-Object { ($_.PSIsContainer -eq $true) -and
(Test-Path($_.Fullname + 'bin\release')) } |
Select-Object Fullname
ForEach ($Path in $Paths)
{
$CopyPath = $Path.Fullname + '\bin\Temp'
$DeletePath = $Path.Fullname + '\bin\Release'
New-Item -ItemType directory -path $CopyPath
Copy-Item $DeletePath $CopyPath -recurse
Remove-Item $DeletePath Recurse
}
And after the build copies it back with:
ForEach ($Path in $Paths)
{
$CopiedPath = $Path.Fullname + '\bin\Temp\'
$DeletedPath = $Path.Fullname + '\bin\Release\'
$Files = Get-ChildItem $CopiedPath -recurse |
where-object {-not $_PSIsContainer}
ForEach ($File in $Files)
{
if(-not (Test-Path ($DeletedPath+$File.Name)))
{
Copy-Item $File.Fullname ($DeletedPath+$File.Name)
}
}
Remove-Item $CopyPath -recurse -force
}
This is pretty clunky and noobish (Sorry, I'm a PowerShell noob drinking from a fire hose), but it works for the purpose and I will clean it up later. However, when it executes the initial copy to the temp directories, it writes a lot of blank lines to the screen, which isn't ideal as I have a message I display while this process is executing to assure our CM doesn't freak out and think it broke, but this message is blown away by the blank lines. Do you know what might be causing this and how I might solve this? I'm using PowerShell 2.0 out of the box and due to the nature of this project I can't upgrade or get any outside libraries. Thanks guys.

If the only thing you're looking to do is clean up the console output, then all you need to do is use the pipeline. You can start the command with [void], which will exclude all information from the pipeline. You can also pipe the whole thing into the Out-Null cmdlet, which will trap all output, except for the lines that don't have output.
The New-Item cmdlet by default returns output to the console on my version of Windows PowerShell (4.0). This may not be true on previous versions, but I think it is... Remove-Item also doesn't return any output, usually. If I were to take a stab, I'd kill output on those lines that use the "Item" noun using one of the methods mentioned above.

Related

Is there a way to add a postfix to this script?

So I asked here before about helping with a script to copy and paste files from one folder to another.
However, after I was done, I found that some of the files went missing. I had 600,393 files but when I checked my new folder it only had 600,361 files.
I think it may have been overwritten by duplicates even though the naming convention was supposed to stop those kinds of problems.
Here's the script
$destfolder = '.\destfolder\'
Get-ChildItem -Recurse -File .\srcfolder\ |
Invoke-Parallel {
$_ | Copy-Item -Destination (
Join-Path $using:destfolder ($_.directory.parent.name, $_.directory.name, $_.name -join '-')
) -Verbose -WhatIf
}
(Thanks to the great dudes on r/software, r/Techsupport, and mklement0)
So is there a way to add a postfix that adds a 0 to the name of any file that has the same name as a file already in a folder?
like directory-subdirectory-0-filename.ext
EDIT- Problem is all the files are read-only not hidden, I don't want any hidden files.
Note that Get-ChildItem doesn't include hidden items by default, which may explain at least part of the the discrepancy.
Use the -Force switch to include hidden items.
Separately / additionally, you can deal with name collisions as follows:
$destfolder = '.\destfolder\'
Get-ChildItem -Force -Recurse -File .\srcfolder\ |
Invoke-Parallel {
$newName = Join-Path $using:destfolder ($_.directory.parent.name, $_.directory.name, $_.name -join '-')
# Try to create the file, but only if it doesn't already exist.
if ($null -eq (New-Item $newName -ErrorAction SilentlyContinue)) {
# File already exists -> create duplicate with GUID.
$newName += '-' + (New-Guid)
}
$_ | Copy-Item -Destination $newName -Verbose
}
Note:
With multi-threaded execution, assigning sequence numbers to duplicates would be a nontrivial undertaking, as each thread would have to "reserve" a sequence number and ensure that no other thread claims it before copying to a file incorporating this number is complete.
To avoid such challenges, the above approach simply appends a - plus a GUID to the target file name.

Remove-Item -Force on NULL Filewatcher file removed 1000 files on my server, is this a Powershell bug? Or just my bad code?

So, I am developing a script using FileSystemWatcher similar to this one: https://powershell.one/tricks/filesystem/filesystemwatcher
I only use the Created event.
I then run the following code on the files that are "Created."
I met a really unexpected error when I ran this code on a file that was already removed by another piece of code. So basically, the "Remove-WrongFileType" function received a file that was NULL, just nothing. And then it just started deleting tons of different files on my server.
I run my script from C:\ and I obviously gave it to high rights. However, I find it really strange that when the $Path is Null, the script just finds files to remove. I've managed to fix this in my code, by checking first if the path to the file leads to something, however I want to learn what caused the script to crash this hard, and why the Get-ChildItem finds files when the $Path is a NULL file. I wonder if this could be some kind of bug in Powershell? (Most likely not.. but I wonder..)
Function Remove-WrongFileType {
Param (
[string]$Path
)
$Files = Get-ChildItem -Path $Path -Force -Recurse
foreach($file in $Files) {
if(-not (Assert-LegalFileType -File $file.FullName){
Remove-Item -Path $file.Fullname -Force
Add-ToLog -logString “File $file was removed because of illegal filetype”
}
}
}
Function Assert-LegalFileType {
Param (
[string]$File
)
if(Test-Path -Path $File -PathType Container){
return $true
}
$fileToCheck = Get-Item -Path $File
$ExtensionOfFile = $fileToCheck.Extension
foreach($type in $AllowedFiles){
if($ExtensionOfFile -match $type) {
return $true
}
}
}
So I looked up what happens when you pass NULL to Get-childitem. And it is a known issue apparently. Get-ChildItem -Path $null does not throw an error #8708
A comment describe the same issue:
One of the side effects of this bug/feature could be to accidentally delete your system when you are using the output of this command piped to say a $_.Delete(). That is exactly what happened when I refactored my code to delete previous test runs; so
From :
Get-ChildItem -Path C:\SourceCodeTLM\testRunResults-Include * -File -Recurse | foreach { $.Delete() }
To:
$testRunResults= "C:\SourceCodeTLM\testRunResults"
Get-ChildItem -Path $testRunResults-Include * -File -Recurse | foreach { $.Delete() }
and forgot to initialize the variable while doing a debug.
In the worst case, I expected an error but instead, the cmd ran and started deleting my current dir content (Which by default was PS C:\windows\system32>).
Before I could understand what happened and pressed ctrl+c; enough files were deleted to corrupt my system. I had to restore and all of my stuff on my machine was lost. I learned this lesson the hard way but maybe others don't have to :). May be giving an error (when null) or keeping this parameter (mandatory) would be better from a risk standpoint :).
So yeah, don’t pass null to get-childitem and try to force delete the output with high privileges.

PowerShell to copy files to destination's subfolders while excluding certain folders in the destination

So I have danced with this off and on throughout the day and the timeless phrase "There's more than one way to skin a cat" keeps coming to mind so I decided to take to the community.
Scenario:
Source folder "C:\Updates" has 100 files of various extensions. All need to be copied to the sub-folders only of "C:\Prod\" overwriting any duplicates that it may find.
The Caveats:
The sub-folder names (destinations) in "C:\Prod" are quite dynamic and change frequently.
A naming convention is used to determine which sub-folders in the destination need to be excluded when the source files are being copied (to retain the original versions). For ease of explanation lets say any folder names starting with "!stop" should be excluded from the copy process. (!stop* if wildcards considered)
So, here I am wanting the input of those greater than I to tackle this in PS if I'm lucky. I've tinkered with Copy-Item and xcopy today so I'm excited to hear other's input.
Thanks!
-Chris
Give this a shot:
Get-ChildItem -Path C:\Prod -Exclude !stop* -Directory `
| ForEach-Object { Copy-Item -Path C:\Updates\* -Destination $_ -Force }
This grabs each folder (the -Directory switch ensures we only grab folders) in C:\Prod that does not match the filter and pipes it to the ForEach-Object command where we are running the Copy-Item command to copy the files to the directory.
The -Directory switch is not available in every version of PowerShell; I do not know which version it was introduced in off the top of my head. If you have an older version of PowerShell that does not support -Directory then you can use this script:
Get-ChildItem -Path C:\Prod -Exclude !stop* `
| Where-Object { $_.PSIsContainer } `
| ForEach-Object { Copy-Item -Path C:\Updates\* -Destination $_ -Force }
To select only sub folders which do not begin with "!stop" do this
$Source = "C:\Updates\*"
$Dest = "C:\Prod"
$Stop = "^!stop"
$Destinations = GCI -Path $Dest |?{$_.PSIsContainer -and $_.Name -notmatch $Stop }
ForEach ($Destination in $Destinations) {
Copy-Item -Path $Source -Destination $Destination.FullName -Force
}
Edited Now copies all files from Update to subs of Source not beginning with "!stop" The -whatif switch shows what would happen, to arm the script remove the -whatif.
Edit2 Streamlined the script. If also Sub/sub-folders of C:\Prod shall receive copies include a -rec option to the gci just in front of he pipe.

Powershell Workflow Chugging at Memory and Crashing

I'm dabbling with workflows in powershell and I'm noticing some odd behavior. The below script will work when the directory doesn't contain a lot of files. After some point it will hold on line 6 (when run in the ise you'll see the workflow status bar), munch up memory, then eventually crash (after at least half an hour). This crash happens when the directory of files is at least 1.25GB, but not when the $Path has only 50mb of files. Here's an easy test:
Workflow Test-Me {
Param
(
$Path = "c:\temp",
$Days = 0
)
$Files = InlineScript{
Get-ChildItem -Path $using:Path -File -Recurse -Force | Where-Object {$_.LastWriteTime -lt ((get-date).AddDays(-$using:Days))}
}
$Files
}
Now the odd thing is that when Get-ChildItem -Path $using:Path -File -Recurse -Force | Where-Object {$_.LastWriteTime -lt ((get-date).AddDays(-$using:Days))} is run from outside of the workflow (in a regular function or just on a line of the shell) it completes in less than a minute, even with 1.25GB of files.
What is the workflow doing that causes it to eat memory, take a long time, and crash? It's obviously doing something unexpected. Again, it works if there's only a few files in the directory.
Also, a solution/workaround would be great.
Research:
Activity to invoke the Microsoft.PowerShell.Management\Get-ChildItem command in a workflow
Running Windows PowerShell Commands in a Workflow
The problem here appears to be with the retention of object data. Adding a select reduces the size of the returned object data so much so that searching 100GB+ did not cause it to crash. Solution is as followed:
Workflow Test-Me {
Param
(
$Path = "c:\temp",
$Days = 0
)
$Files = InlineScript{
Get-ChildItem -Path $using:Path -File -Recurse -Force | Where-Object {$_.LastWriteTime -lt ((get-date).AddDays(-$using:Days))} | select filename
}
$Files
}

Deleting cabinet files

I'm trying to create a script to delete cabinet files in virtual servers. For some reason, the code that I've created ends up not deleting any cabinet files and instead tries to delete the entire WINDOWS Directory, and I have no idea why this is occurring. Was curious if anyone might have any ideas on what the issue may be, since I can't find anything:
$dir = "\\$server" + '\C$\windows'
$cabinetArray = #()
foreach ($item in get-childitem -path $dir){
if ($item.name -like "*.cab"){
$cabinetArray = $cabinetArray + $item
}
}
for ($i = 0; $i -le $cabinetArray.length; $i++){
$removal = $dir + "\" + $cabinetArray[$i]
remove-item $removal -force -recurse
}
I did some testing and it seems that for some reason my array that I'm trying to use to gather all the cabinet files isn't even getting filled for some reason. I'm not sure if there's a specific way to only gather the .cab files since right now whenever I run this on my test server it tries deleting everything.
I don't know if deleting all the cab files in that folder is a good idea or not, but I'll answer your question. You're doing a lot of math and building your own collection of objects when PoweShell will do it all for you. Try something like this:
$dir = "\\" + $server + '\C$\windows'
$cabinetFiles = Get-ChildItem -Path $dir -Filter "*.cab" -Recurse
$cabinetFiles | %{
Remove-Item -Path $_.FullName -Force
}
Or, as a one liner:
Get-ChildItem -Path ("\\" + $server + '\C$\windows') -Filter "*.cab" -Recurse | %{Remove-Item -Path $_.FullName -Force}
Use the pipeline, here's a simplified version of your code (remove -WhatIf do delete the files). The code gets all *.cab files from the windows directory of the remote box (recursively), makes sure that only file objects passes on and then deletes them.
Get-ChildItem "\\$server\admin$" -Filter *.cab -Recurse |
Where-Object {!$_.PSIsContainer} |
Remove-Item -Force -WhatIf
For some reason, the code that I've created ends up not deleting any cabinet files and instead tries to delete the entire WINDOWS Directory, and I have no idea why this is occurring.
It is occurring because your for loop is being entered, and that is happening because $cabinetArray's length is zero. Once the for loop is entered, the $removal variable is assigned the value of $dir plus a trailing backslash. You are then calling remove-item on the windows directory.