OneDrive on-demand still isn't bullet proof

%3CLINGO-SUB%20id%3D%22lingo-sub-886676%22%20slang%3D%22en-US%22%3EOneDrive%20on-demand%20still%20isn't%20bullet%20proof%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-886676%22%20slang%3D%22en-US%22%3E%3CP%3EVery%20simple%20PowerShell%20example%20that%20writes%20the%20current%20date%20and%20time%20to%20a%20readme%20file%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSTRONG%3E%22Backed%20up%20%24(Get-Date)%22%20%26gt%3B%20%22%24OneDrive%5CReadme.txt%22%3C%2FSTRONG%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%24OneDrive%20is%20the%20path%20to%20the%20root%20of%20the%20local%20OneDrive%20folder.%20If%20Readme.txt%20exists%20but%20isn't%20downloaded%2C%20this%20command%20fails%20with%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSTRONG%3Eout-file%20%3A%20The%20cloud%20operation%20was%20unsuccessful.%3C%2FSTRONG%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EOneDrive%20and%20Windows%2010%20is%20obviously%20still%20not%20integrated%20tightly%20enough.%20One%20assumes%20that%20out-file%20performs%20a%20pretty%20standard%20Windows%20file%20open%20command.%20One%20assumes%20that%20it%20shouldn't%20return%20until%20the%20file%20is%20downloaded.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-886676%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EOneDrive%20for%20Business%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-886716%22%20slang%3D%22en-US%22%3ERe%3A%20OneDrive%20on-demand%20still%20isn't%20bullet%20proof%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-886716%22%20slang%3D%22en-US%22%3E%3CP%3EThe%20sketchy%20workaround%20is%20to%20use%20a%20function%20like%20this%20to%20force%20OneDrive%20to%20download%20the%20file%20first%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSTRONG%3EFunction%20GetFile(%24Path)%20%7B%3C%2FSTRONG%3E%3CBR%20%2F%3E%3CSTRONG%3E%26nbsp%3B%20%26nbsp%3B%20If%20(Test-Path%20%24Path)%20%7B%3C%2FSTRONG%3E%3CBR%20%2F%3E%3CSTRONG%3E%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3B%20%24File%20%3D%20%5BSystem.IO.File%5D%3A%3AOpenRead(%24Path)%3C%2FSTRONG%3E%3CBR%20%2F%3E%3CSTRONG%3E%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3B%20%24File.ReadByte()%20%7C%20Out-Null%3C%2FSTRONG%3E%3CBR%20%2F%3E%3CSTRONG%3E%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3B%20%24File.Close()%3C%2FSTRONG%3E%3CBR%20%2F%3E%3CSTRONG%3E%26nbsp%3B%20%26nbsp%3B%20%7D%3C%2FSTRONG%3E%3CBR%20%2F%3E%3CSTRONG%3E%7D%3C%2FSTRONG%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ENot%20ideal!%20And%20means%20a%20lot%20of%20re-working%20of%20PowerShell%20scripts%20that%20happen%20to%20be%20expected%20to%20work%20on%20OneDrive%20file%20systems.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-888084%22%20slang%3D%22en-US%22%3ERe%3A%20OneDrive%20on-demand%20still%20isn't%20bullet%20proof%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-888084%22%20slang%3D%22en-US%22%3E%3CP%3EI've%20reported%20a%20similar%20issue%20with%20PowerShell%207%20and%20the%20fix%20has%20already%20been%20released%20in%20one%20of%20the%20preview%20builds%20IIRC.%20But%20yeah%2C%20don't%20expect%20the%20different%20teams%20at%20Microsoft%20to%20talk%20to%20each%20other%20%3AD%3C%2Fimg%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-888470%22%20slang%3D%22en-US%22%3ERe%3A%20OneDrive%20on-demand%20still%20isn't%20bullet%20proof%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-888470%22%20slang%3D%22en-US%22%3EWhat%20worries%20me%20most%20about%20this%20is%20that%20PowerShell%20is%20probably%20using%20pretty%20basic%20Windows%20API%20calls%20for%20file%20access%20-%20maybe%20%5BSystem.IO.File%5D.%20Surely%20these%20calls%20should%20not%20return%20if%20any%20app%20carries%20out%20file%20IO%20on%20an%20on-demand%20file%20until%20either%20the%20file%20has%20been%20deleted%20cleanly%20(if%20a%20new%20file%20is%20been%20created)%20or%20it's%20downloaded%20entirely.%20If%20PowerShell%20has%20a%20problem%2C%20then%20who%20knows%20what%20other%20apps%20will%20do.%20The%20fix%20for%20this%20must%20be%20with%20Windows%2010%2FOneDrive%2C%20not%20PowerShell.%20If%20it's%20in%20PowerShell%2C%20then%20they%20are%20working%20around%20some%20pretty%20dangerous%20problems%20in%20OneDrive%20on-demand%3C%2FLINGO-BODY%3E
Contributor

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.

3 Replies

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 :D

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