Forum Discussion
Powershell script move contents of child folder to parent, go to next folder and repeat
I've reproduced the "process lock" scenario you've run into, and the outcome matches expectations on my side - keeping in mind none of this requires administrative access (I'm always operating as an unprivileged user in accordance with best practice).
In the output example below, we see the "before" and "after" file layout, where I've deliberately locked the following path by virtue of changing the command prompt session to using it:
D:\Data\Temp\Forum\Root\Parent1\Child1
As a result, when I've then run the script, this path failed to be moved, hence the two files it contains remain in their original location - nothing was deleted.
Because this specific version of "Child1" failed, it allowed the next iteration of "Child1" - located under Parent2 - to succeed in moving - all of which can be seen in the "after" directory listing.
The key takeaway though is that nothing was deleted, so if you're seeing that, then I'm unsure how that's come about.
Output
Cheers,
Lain
Hi Lain
I must apoligize for not replying until now but I was called away from home for a few days.
Thank you for your kind help which I really do appreciate.
I have now tested your code suggestion but sadly, for me, it does not work as expected.
For testing I created a Test folder in my C drive root.
Inside the Test Folder I created 4 Parent folders.
Inside Parent 1 I created 2 child folders (as a parent may have none or many child folders)
Inside Parent 3 - 4 I created one child folder in each.
Inside each child folder I placed 2 text files, one audio .flac file and a .jpg file
I also used variations of the naming format and used characters such as (, ), [ and ] to reflect the real world folder names
As a illistration I attach a screen shot
I then modified your code to reflect the test folder...
$Root = "C:\Test";
I then opened Powershell changed to my C drive, pasted your code and hit enter
Powershell returned the error as below
Remove-Item : Cannot remove item C:\Test\01 Parent [For] a (Test) 1\Child 1 [For] a (Test): The process cannot access the file 'C:\Test\01 Parent [For] a (Test) 1\Child 1 [For] a (Test)' because it is being used by another process.
At line:47 char:18
+ $_ | Remove-Item -Recurse -ErrorAction:Stop;
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : WriteError: (Child 1 [For] a (Test):DirectoryInfo) [Remove-Item], IOException
+ FullyQualifiedErrorId : RemoveFileSystemItemIOError,Microsoft.PowerShell.Commands.RemoveItemCommand
PS C:\>
When I checked the child folders, the code had not removed any of them.
in
01 Parent [For] a (Test) 1\Child 1 [For] a (Test)
It had deleted all of the test files but it did not copy or move them up a level to the parent folder, it had simply deleted them.
in
02 Parent (For) a [Test] 2\Child 2 [For] a (Test)
03 Parent (For) - a (Test) 3\Child 3 [For] a (Test)
04 Parent + a [Test] 4\Child 4 + a [Test]
And a image for good measure
The code did not change anything with all of the test files still inside the Child folders
I have tested this with Powershell as an Admin and without but the result is still the same.
I've reproduced the "process lock" scenario you've run into, and the outcome matches expectations on my side - keeping in mind none of this requires administrative access (I'm always operating as an unprivileged user in accordance with best practice).
In the output example below, we see the "before" and "after" file layout, where I've deliberately locked the following path by virtue of changing the command prompt session to using it:
D:\Data\Temp\Forum\Root\Parent1\Child1
As a result, when I've then run the script, this path failed to be moved, hence the two files it contains remain in their original location - nothing was deleted.
Because this specific version of "Child1" failed, it allowed the next iteration of "Child1" - located under Parent2 - to succeed in moving - all of which can be seen in the "after" directory listing.
The key takeaway though is that nothing was deleted, so if you're seeing that, then I'm unsure how that's come about.
Output
Cheers,
Lain