Drive File Stream & Concurrent Access

This September Google released Drive File Stream to G Suite users. Drive File Stream is an alternative to the Google Drive sync client, which has been renamed to “Google Backup & Sync”.

Google Drive File Stream creates a local, virtual/mounted drive dubbed “G” which is mostly indistinguishable to the user from an actual local drive or a network share. The root of G has just “My Drive” for the user’s Google Drive files and “Team Drives” for the user’s Team Drives. Unlike Google Drive, files are not necessarily synced to the local computer, but are streamed on demand when users open them, with a healthy level of local caching to speed the process.

We’ve been testing Drive File Stream in a production environment, and most recently addressed what happens when multiple users open the same file. While Google Drive’s Docs, Sheets, and Slides are designed for concurrent users, traditional applications are not.

We never deployed Google Drive (I mean “Backup & Sync”) to users’ PCs, so we didn’t have to worry about how applications would handle multiple users opening a Word doc, for example. And, it should be noted that Google’s Backup & Sync application handles concurrent users differently than Drive File Stream. This post is about Drive File Stream’s behavior in a mixed Windows environment (Windows 7, Windows 10).

So what happens when two users attempt to open the same file? In summary:

  • It depends on the application.
  • Microsoft Office Applications, whose file type are most likely to be stored on Drive File Stream, operate similarly to when concurrent users attempt to edit a file on a network share, with an important distinction (see below).
  • Other applications will vary, but that’s the case with network shares too.

In long form:

This is largely dependent on the design of the application. As of the publication of this post, Drive File Stream does not intervene to warn a user that a file in a shared folder or Team Drive is in use by another user. By design, software applications reading / writing to your new G Drive treat it like a network share. Unfortunately, how applications warn users about another user’s activities in the same file – even on network drives – leaves much to be desired.

On a traditional network share, Microsoft Office applications like Word, Excel or PowerPoint will warn you if you’re opening a file that is currently in use:

Excel warns a user that the file they're opening is locked for editing.
Excel warns a user that the file they’re opening is locked for editing.

The warning above appears when users first open a document already in use, which gives users fair warning before they start creating work product. They’re warned that making changes could make for trouble when they’re forced to Save As and later forced to merge their changes with those of another coworker.

That privilege is application-specific, however, even among the same developers. Microsoft Notepad won’t give you such a warning, and happily allows multiple users to overwrite other users’ work stored on a network share without a thought.

The same discordant “warning” system exists for Drive File Stream. When I open a Microsoft Office file already in use, I am not warned of that fact ahead of time. Instead, I’m warned when I attempt to save my changes, and only if the other user has made changes of their own.

I saved an Excel file that had been edited by another user minutes before I hit Save.
I saved an Excel file that had been edited by another user minutes before I hit Save.

This can be annoying for both users. The user who made and saved their changes first stands to lose their work, temporarily (see below). The user who saved their changes last will now need to compare both documents manually and merge changes.

One saving grace of this ill-timed notification is that anything stored in Google Drive is versioned, and an overridden change can be recovered within 30 days. Still, someone must now merge changes that they may not have bothered to make had they been warned ahead of time.

Applications that are designed to expect an open file to be changed while it is open, and have logic to merge those changes, don’t present an issue. For example, we use KeePass Professional, which is designed not just for multiple users but for concurrent users across multiple access points from SFTP to Dropbox. We use KeePass with success over Drive File Stream, and we didn’t configure KeePass any differently than if it were on a traditional network share. Since KeePass already has a sturdy synchronization feature that expects a currently-open database file to be modified by another network user, Drive File Stream doesn’t present an environment much different than a traditional network drive.

KeePass asks if the user wants to syncronize their most recent changes with changes made since the user first opened the database.
KeePass asks if the user wants to syncronize their most recent changes with changes made since the user first opened the database.

That said, I expected Microsoft Access to fail hard over Drive File Stream, but my initial – very basic – test was a success. Access is certainly designed for an open file to be modified by other users, however when that happens both users are modifying the same file at once. Since Drive File Stream is really making a local copy of a single file, I expected there to be merge issues.

I created a database and a sample table with an auto-increment field (ID) and opened the database on two computers, Computer A and Computer B. Then I:

  1. Added the first record (ID 1) on Computer A
  2. Added a second record on Computer B. That record correctly got the ID of 2
  3. Added a third record on Computer A. That record correctly got the ID of 3

A simple test, but Access did exceed my expectations at least in this limited regard. Still, I think I would be wary about putting a production Access Database on Drive File Stream.