Tierd storage spaces powershell path limit (Windows 10)

While working on my Set-StaticTier.ps1-script (will post a link later) I run into a strange 213 character path limit for the powershell commands Set-FileStorageTier and Clear-FileStorageTier on Windows 10 (1909).

First, lets try to create a folder with a 260 character name:

$Folder = "12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890"
$Folder.Length
New-Item -ItemType Directory -Path h: -Name $Folder

(I don't know why the HTML-generator make a red box around : )
This will result in "260" followed by this error:

New-Item : The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
At line:1 char:1
+ New-Item -ItemType Directory -Path h: -Name $Folder
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : WriteError: (H:\123456789012...678901234567890:String) [New-Item], PathTooLongException

    + FullyQualifiedErrorId : CreateDirectoryIOError,Microsoft.PowerShell.Commands.NewItemCommand

Ok, we now know that the full path must be shortar than 260 characters.


Lets try again with 213 characters in the full path, that is below the path limit.

First we set the variable for the folder name, and then measure how many characters we got.

$Folder = "12345678901234567890123456789012345678901234567189012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456790123456789012345"
$Folder.Length

This will result in "185".

Then we do the same for for the file.

$File = "12345678901234567890.txt"
$File.Length

This will result in "24".

If we add the  characters needed for the full path, drive letter + :\ is 3, and we need a backslash between the folder and file, that sums 4.

4 + $Folder.Length + $File.Length

This will result in "213".

Lets create the test-folder and file

New-Item -ItemType Directory -Path h: -Name $Folder
New-Item -ItemType File -Path "H:\$Folder" -Name $File
$FileToSet = (Get-ChildItem -Path h:\$Folder).FullName
$FileToSet.Length

This will result in "213". Good, then we did a proper calculation.

Now lets try the powershell commands to set/clear DesirerStorageTierClass:

Test-Path $FileToSet
Set-FileStorageTier -FilePath $FileToSet -DesiredStorageTierClass Capacity
Clear-FileStorageTier -FilePath $FileToSet

We run the Test-Path just to make sure that the path exists to remove that to our problems. Since we only have 212 characters in the path, we got no errors.

Lets do this all over, but we'll add a character to our file name.

$File = "123456789012345678901.txt"
$File.Length

This will result in "25".

After we create the folder and file we check the path length again:

$FileToSet.Length

This will result in "214".

Now lets try the powershell commands to set/clear DesirerStorageTierClass:

Test-Path $FileToSet

First we get a "True" from the Test-path, nothing wrong there.

Now lets run the Set-FileStorageTier command:

Set-FileStorageTier -FilePath $FileToSet -DesiredStorageTierClass Capacity

This results in an error:

Set-FileStorageTier : Invalid Parameter
Activity ID: {284aa8c7-35f3-460f-9980-6897ad86f43d}
At line:1 char:1
+ Set-FileStorageTier -FilePath $FileToSet -DesiredStorageTierClass Cap ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (StorageWMI:ROOT/Microsoft/...FileStorageTier) [Set-FileStorageTier], CimException
    + FullyQualifiedErrorId : StorageWMI 5,Set-FileStorageTier

Clear-FileStorageTier -FilePath $FileToSet

This also results in an error:

Clear-FileStorageTier : Invalid Parameter Activity ID: {ff02b437-b439-4952-a271-a8dff5c6be13} At line:1 char:1 + Clear-FileStorageTier -FilePath $FileToSet + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidArgument: (StorageWMI:ROOT/Microsoft/...FileStorageTier) [Clear-FileStorageTier], CimException + FullyQualifiedErrorId : StorageWMI 5,Clear-FileStorageTier


What have we learned from this?

The commands to set or clear a file to a desired storage tier class does not support file paths longer than 213 characters. Why is this? I have no idea!
I've search for some documentation regarding storage spaces maximum path lenghts but cannot find anything that says there is a different length limit while using a tierd storage space virtual disk.

If anyone uses tiered storage spaces virtual disks on a Windows Server-version, it would be very interesting to know if the same limit applies to the server version as on Windows 10.

7za.exe vs 7z.exe (7-Zip 9.20 vs 19.0)

While working with a completely different task I found an old backup job using 7za.exe (from 7-zip) to compress some SQL backup files.

Syntax was like this:
7za.exe -a backup.7zip c:\backupfolder -mx1 -mmt

The "-mx1" means it will compress using the fastest compression, which basically is just like "tar", it takes all the files and put them in a combined file, and "-mmt" enables multi threading to speed things up.

What made me investigate this further was the fact that the CPU & disk load on the server was very low, It was hardly noticeable at all.

I am currently building a new main computer for home, and are running some benchmarks on different combinations of RAID-levels and SSD/HDDs (will be a new blog post about this in the furure), so I took one of my test folders with mixed files created by the Intel NAS Performance Toolkit and run some compression testing.

The version of 7za.exe was from 7-Zip 9.20 that was released 2010-11-18 and the 7z.exe is from the latest stable release 19.0 from 2019-02-21.

I made short powershell script to automate the benchmark, it looks like this:

(sorry about the bad code print on the blog, If anyone know how to embedd code on blogger, please let me know!)

ForEach ($number in 1..9 ) { $MeasuredTime = Measure-Command { Start-process "D:\Downloads\7za920\7za.exe" -ArgumentList "a","c:\temp\7za-NAS_Performance_Toolkit-$($number).7z","R:\NAS_Performance_Toolkit","-mx$($number)","-mmt" -Wait } $TimeItTook = "$($MeasuredTime.Hours)h.$($MeasuredTime.Minutes)m.$($MeasuredTime.Seconds)s.$($MeasuredTime.Milliseconds)ms" Rename-Item -NewName "c:\temp\7za-NAS_Performance_Toolkit-$($number)-$($TimeItTook).7z" -Path "c:\temp\7za-NAS_Performance_Toolkit-$($number).7z" }

It will create 7 files with the time it took to create in the file name.

Then I run the same using 7z.exe and it looks almost the same:
(I didnt know how long it would take for the old version so I added hours just in case)

ForEach ($number in 1..9 ) { $MeasuredTime = Measure-Command { Start-process "D:\Downloads\7z1900-x64\7z.exe" -ArgumentList "a","c:\temp\7z-NAS_Performance_Toolkit-$($number).7z","R:\NAS_Performance_Toolkit","-mx$($number)","-mmt" -Wait } $TimeItTook = "$($MeasuredTime.Minutes)m.$($MeasuredTime.Seconds)s.$($MeasuredTime.Milliseconds)ms" Rename-Item -NewName "c:\temp\7z-NAS_Performance_Toolkit-$($number)-$($TimeItTook).7z" -Path "c:\temp\7z-NAS_Performance_Toolkit-$($number).7z" }

When I run the second tests using 7z.exe I could see that CPU usage got to 100% and the disk write speeds when up the roof. Good!

Here are the results:

As you can see the new version is about 10 times faster than the old version.
It also seems like the test files created by the Intel NASPT software is very easily compressed.

To summarize
7za.exe version 9.20 took 11 min 33 seconds (with the -mx1 setting)
7za.exe version 19.0 took 54 seconds (with the -mx1 setting)

This also applied when I tested this on some large SQL backups.
7za.exe took about 2 hours to compress the SQL files and 7z.exe took about 20 minutes to do the same on the same machine.

I also run a compression with the -mx9 flag on the SQL files and the .7z file shrink from abouit 20GB to 11 GB (but it took over 5 hours)

Can we learn anything from this?
Well, I think we should replace all usage of the older 7za.exe with the much faster 7z.exe!
We should also runs some tests on our scheduled tasks to find the sweet-spot between time (CPU usage) and file size.

Use Homey, Netatmo and IFTTT to park Husqvarna Automower when raining

To begin with I tried to use only IFTTT and Netatmo to park my Automower (its name is Olle and its a model 430x), but for some unknown reason it began to flip flop, where it could say "its raining", "its not raining" on repeat for hours. So I decided to control this using Homey instead, and here is how I set it up.

To begin with, you need to install the "Countdown Timers" app, and the IFTTT app, and the Netatmo app (You also need a Netatmo weather station).

You need to create a "timeout timer" for when rain stopped, I call this timer "olle_parked_timeout".

The variable that is used for setting the timeout time is called "Rain_wait_time".
To make sure flows are not repeating them self I use a Yes/no (boolean) variable called "Olle_should_be_parked".

Let the fun begin. I check for rain every 10 minutes. When I started using Homey I set flows to trigger on variable change etc, but sometimes that did not trigger flows. Using a 10 min interval, I know it will re-trigger if it missed the first time.

In order, when rain has been detected by this first flow, it will set the variable "Olle_should_be_parked" to yes and also it will stop the timer in case it has rained earlier today.

The action is "Set Olle_should_be_parked to Yes"

When the Olle_should_be_parked is changed to yes it will trigger the second flow that will send the command to IFTTT and create a notification in the app.

When rain stops, calculate the timeout value by calling a flow that calls the three different flows that will set the timeout value depending on how much rain has fallen today.

When the timer finally runs out (note that it will stop/restart if rain is detected again before the timer runs out) it will change the "Olle_should_be_parked" to no

The action is "Set Olle_should_be_parked to No"

When "Olle_should_be_parked" is changed to no the last flow will send the instruction to IFTTT to resume on schedule and create a notification in the Homey app.

Fix for Dropbox not running after client update

I got tired of my Dropbox client killing itself and not re-launching while it upgrades the client so I made these two scripts to fix the problem. The first script checks if Dropbox is running and starts the client if it is not. The second script launches the first script without the powershell window popup.

1. Start-Dropbox.ps1

# Start-Dropbox.ps1 begins
If ( -not (Get-Process -Name Dropbox -ErrorAction SilentlyContinue)) {
& "${env:ProgramFiles(x86)}\Dropbox\Client\Dropbox.exe"
}
# Start-Dropbox.ps1 ends

2. Start-Dropbox-launcher.vbs

' Start-Dropbox-launcher.vbs begins
Dim shell,command Set shell = CreateObject("WScript.Shell") windowsdir = shell.ExpandEnvironmentStrings("%windir%") programdir = shell.ExpandEnvironmentStrings("%programfiles%") Dim ScriptPath ScriptPath = Left(WScript.ScriptFullName, Len(WScript.ScriptFullName) - Len(WScript.ScriptName)) command =("""" & windowsdir & "\system32\WindowsPowerShell\v1.0\powershell.exe""" & " -ExecutionPolicy Bypass -NoLogo -NonInteractive -NoProfile -WindowStyle Hidden -File " & """" & ScriptPath & "\Start-Dropbox.ps1""") shell.Run command,0
' Start-Dropbox-launcher.vbs ends

Create a scheduled task that runs "C:\Windows\System32\wscript.exe Start-Dropbox-launcher.vbs"
Set the work folder the wherever the scripts are located.

I chose to run the script once an hour with 10 min random delay.

Problem solved, yay! :)