OneDrive on-demand still isn't bullet proof

[rob_nicholson_helios]

Very simple PowerShell example that writes the current date and time to a readme file:

"Backed up $(Get-Date)" > "$OneDrive\Readme.txt"

$OneDrive is the path to the root of the local OneDrive folder. If Readme.txt exists but isn't downloaded, this command fails with:

out-file : The cloud operation was unsuccessful.

OneDrive and Windows 10 is obviously still not integrated tightly enough. One assumes that out-file performs a pretty standard Windows file open command. One assumes that it shouldn't return until the file is downloaded.

[#2]

The sketchy workaround is to use a function like this to force OneDrive to download the file first:

Function GetFile($Path) {
    If (Test-Path $Path) {
        $File = [System.IO.File]::OpenRead($Path)
        $File.ReadByte() | Out-Null
        $File.Close()
    }
}

Not ideal! And means a lot of re-working of PowerShell scripts that happen to be expected to work on OneDrive file systems.

[#3]

I've reported a similar issue with PowerShell 7 and the fix has already been released in one of the preview builds IIRC. But yeah, don't expect the different teams at Microsoft to talk to each other :D

[#4]

What worries me most about this is that PowerShell is probably using pretty basic Windows API calls for file access - maybe [System.IO.File]. Surely these calls should not return if any app carries out file IO on an on-demand file until either the file has been deleted cleanly (if a new file is been created) or it's downloaded entirely. If PowerShell has a problem, then who knows what other apps will do. The fix for this must be with Windows 10/OneDrive, not PowerShell. If it's in PowerShell, then they are working around some pretty dangerous problems in OneDrive on-demand