Eliminating Thumbs db Files: A Guide

At times, I shred downloaded content that includes Thumbs.db files. However, my daemon encounters an issue as Windoze recognizes them as system files and denies access. Although the exception does not harm the daemon, I can delete the Thumbs.db files immediately without any trouble through File Explorer when I see the complaint in the log.


Question:

I am facing a Windows issue where
delete Thumbs.db
cannot be accessed because the system detects them as already open.

Initially, it should be noted that the option of utilizing regedit to facilitate the deletion of the aforementioned content is available. Unfortunately, as I am not in possession of the
network folder
, I am unable to gain entry to the server and proceed with this method. Nonetheless, for those who may find it useful, the steps required to carry out this process are as follows:

 add a new "Explorer" Registry path:
 HKEY_CURRENT_USERSoftwarePoliciesMicrosoftWindowsExplorer
 and then add a DWORD entry called "DisableThumbsDBOnNetworkFolders", and set it to 1.

By renaming Thumbs.db manually to “ThisSucks.db”, I am able to delete the file. Since I have multiple folders with Thumbs.db files, I plan to create a PowerShell script that can rename or delete them all.

Upon collecting the thumbs, the Write-Host print for each file becomes visible, however, renaming them results in an error message of “Cannot rename because file does not exist”.

[System.Object[]] $directory = Get-ChildItem -Path $Path -Filter "*.db" -Force -Recurse;
foreach($file in $directory){
    Write-Host -ForegroundColor Green "Found Thumb files";
    Rename-Item $file "StupidFile.db";
} 

Any ideas?


Solution:

In a comment on the question, TessellatingHeckler offered a crucial pointer.

It may come as a surprise that when

[System.IO.FileInfo]

instances are returned by

Get-ChildItem

, they attach to

Rename-Item

‘s

-Path

parameter as strings when directly passed as arguments. Additionally, when used in a string context, a

[System.IO.FileInfo]

instance only expands to its filename and not the complete path.

Unless the

[System.IO.FileInfo]

instance is pointing to a file in the present directory, it will not be detected by

Rename-Item

.

The pitfall doesn’t apply when binding instances of

[System.IO.FileInfo]

through the pipeline. To bind to

-Path

, use the

.PSPath

property. Thus, the following can be utilized.

 Get-ChildItem -Path $Path -Filter '*.db' -Force -Recurse |
   Rename-Item -NewName 'StupidFile.sb' -WhatIf

Observe the

-WhatIf

toggle that displays a preview of the renaming actions. To execute the renaming, eliminate this toggle.


Regarding your initial statement represented by

[System.Object[]] $directory = Get-ChildItem ...

, please note the following.

Instead of utilizing casting to

[System.Object[]]

, the array subexpression operator

@()

can be employed to guarantee that a command’s output is handled as an array, regardless of whether it yields a solitary item or none.

$directory = @(Get-ChildItem ...)

However, usually there is no need to do so on PSv3+ as any individual value can be utilized as an array due to its scalar nature. For instance:

> $scalar = 'a single value'
# Treat $scalar as a collection:
# A scalar as a collection by definition has count 1.
> $scalar.Count
1  
# Enumerate the scalar in a foreach loop.
> foreach ($itm in $scalar) { "[$itm]" }
[a single value]
# Process the scalar in a pipeline using the ForEach-Object cmdlet.
> $scalar | ForEach-Object { "[$_]" }
[a single value]

Frequently Asked Questions