Re: Wish list: Cygwin `mv` to move OneDrive files without downloading them

[Sam Edge <sam.edge@gmx.com>]

On 14/06/2022 12:25, Adam Dinwoodie wrote:
 > Microsoft OneDrive has a "Files On-Demand" function, where it will
 > synchronise file metadata to a local system, but won't actually download
 > the file content until an application attempts to read the content.
 > When moving a file within Cygwin using `mv`, the file always gets
 > downloaded, which seems like it shouldn't be necessary.  Is there any
 > way to have `mv` (and presumably the underlying rename call) work
 > without downloading the file content in this circumstance? It'd
 > definitely make some of my life easier, but I'm not sure if it's a
 > trivial issue, one that would require years of work, or somwhere in
 > between...
 >
 > As best I can tell, `mv` doesn't need to know the content of the file,
 > at least as long as it's not moving the file outside of OneDrive; it
 > feels very similar to me to moving a file within a partition on *nix:
 > generally it's just a case of updating the directory records, with no
 > need to look at the file content.
 >
 > This does work as desired from within PowerShell: PowerShell's
 > `Move-Item` won't download a file that's not currently stored on the
 > local system.  So it's presumably possible to achieve this, although I
 > don't know if it'd rely on non-public Microsoft APIs, and/or lots more
 > complexity in the Cygwin code.
 >
 > Simple demonstration below, showing the different behaviours of
 > PowerShell versus Cygwin.  I've not included a cygcheck.out, as I'm
 > pretty sure this is much closer to a feature request than a problem
 > report, but let me know if I've got that wrong.

Greetings Adam.

I wasn't even aware you could do that with OneDrive - there's still no
Explorer
way of doing it in Windows 10 21H2 as far as I can see. Thanks for the
info. :-)

I imagine Cygwin doesn't know about the extended attributes being used
within
the local copy of your OneDrive directory so it is doing the move using the
underlying POSIX 'rename within mount' API which hopefully uses the Win32
'rename' but not in a way that carries the new 'O' attribute.

Presumably PowerShell's Move-Item does use the right flags to the Win32 API
call.

One of the problems the Cygwin maintainers have is that Microsoft introduces
'enhancements' to NTFS & the Win32 API arbitrarily in Windows updates
without
announcing them so it's a game of whack'a'mole.

--
Sam Edge