Windows 10 April 2018 Update Breaks SVN in Work Folders

[Gary Cane]

We use Windows Work Folders to automatically sync files from a local computer to our servers.  We also use SVN.  Both have worked fine together until the recent Windows 10 version 1803 release.  With this update we are seeing that TortoiseSVN no longer recognizes the files as part of an SVN working copy.   If I get a fresh checkout, TortoiseSVN does recognize the files at first, but as soon as Work Folders syncs them they are no longer recognized.

This post describes changes to Work Folders in the update: https://blogs.technet.microsoft.com/filecab/2018/01/08/work-folders-on-demand-file-access-feature-for-windows-10/

This post describes a similar issue with One Drive (which I believe Work Folders is based off of): https://groups.google.com/forum/#!topic/tortoisesvn/Skps6WZRE_c 

I have tried every combination of enabling / disabling the on-demand file access feature and in all cases the problem remains.  

The other interesting thing is the command line version of SVN works fine.  Doing a cleanup or update of the working folder from command line SVN does not help TortoiseSVN recognize it.

We are using TortoiseSVN 1.10.0, Build 28176 - 64 Bit , 2018/04/14 08:00:32.  Has anyone else experienced this issue or have any suggestions?

[Stefan]

After you've disabled the on-demand access (you can do that for the working copy folder alone), you have to wait a while until *all* files (including those inside the usually hidden .svn folder!) show the green overlay (see the link to the blog post you just posted, there are images on how that overlay has to look).

Meaning: all files have to be locally available immediately.

The reason some apps can work with those on-demand files and not TSVN is that TSVN is a shell extension, and if a shell extension takes too long for a specific task, the explorer will kill it to prevent the whole explorer/desktop from freezing. That's why TSVN won't work with on-demand files: it takes too long to fetch them and so the explorer process just stops the shell extension part of TSVN.

[Gary Cane]

Stefan -- thanks for the reply.  I have tried this hours after all the files in the working folder and the associated .svn folder are solid green and synced (including all sub-folders of the .svn folder.)  TSVN still does not recognize them as SVN files.

[Gary Cane]

Some additional information that may be useful.  If I unplug the network cable the files are all still there . . . I can edit the files, etc. and TSVN is not noticing them as SVN files.  Next, I copy the folder (with the network cable still unplugged) to a location not in the Work Folders tree.  TSVN does recognize the copy as SVN files.  Other thing is that right click -> properties on files in the Work Folders version does not show the TSVN tab.  Properties on the copied version does show the TSVN tab.

On Thursday, May 17, 2018 at 12:37:12 PM UTC-4, Stefan wrote:

[Stefan]

I found out why it doesn't work (sorry, but this is now very technical):

The on-demand files in Onedrive are implemented using reparse points. That's also why NTFS is required and Onedrive won't work with FAT32 or other file systems.

Problem is, most applications don't work properly with reparse points, so Onedrive also implements a file system filter which makes sure that applications won't even see the reparse points but only normal files. But here's the big problem: the file system filter is deactivated for the explorer process!

You can test this yourself if you open e.g. notepad and open the file-open dialog: there you can right-click and the TSVN menu shows up properly. Only in Explorer the menu doesn't show.

And since the file system filter is a driver, I can't work around this.

The only way to get the context menu working for Onedrive folders is to actually handle the reparse points in the svn library. While trying to figure out the problem I also checked the svn library code and to make everything work properly with reparse points is not quite easy. Especially since to test this, you have to use a shell extension - as I said all other apps/processes 'see' the real files due to the file system filter.

For example, the TSVN dialogs all work properly if you start them manually, e.g.

TortoiseProc.exe /command:repostatus /path:"d:\Onedrive\svnproject"

will work just fine.

One more thing: while I could get the context menu to work eventually, the overlay icons would never work: Onedrive has it's own view implemented in Explorer, and that view does not show overlay icons from other shell extensions. So those will never work.

Sorry for the bad news.

Stefan

[Gary Cane]

Stefan -- thanks for looking into this.  I was able to confirm everything thing you wrote about for One Drive is also true for Work Folders.  It appears Microsoft added a feature to Work Folders we have no use for (on-demand) and in the process broke something we use daily . . . painful.  

In case someone else comes across this, I thought I'd share some options we looked into:

* Use an alternative file explorer to Windows File Explorer: There are several options available (just Google 'Alternative to File Explorer').  For us, Explorer++ was the simplest solution that had features we could use.  It does show the TSVN context menu when you right click on a file / directory in Work Folders, but as Stefan mentions, the icon overlays will not appear.

* Use an alternative SVN GUI to TortoiseSVN: We were not interested in this path as TSVN has everything we need, but there are others out there that are not integrated into File Explorer and will most likely work.  As mentioned previously, command line SVN works.  I'm guessing SVN tools that are integrated into various development environments will also work.

* Use an alternative to Work Folders to sync local client files to a backup server: In the end, this is most likely the path we are going to take.  We are currently focusing on FreeFileSync.  Not as integrated or all the features as Windows Work Folders, but appears to give us the functionality we need and is compatible with TSVN.