Forum Discussion
OneDrive on-demand still isn't bullet proof
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...
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.
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 😄
- 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
