PlasticDrive – dynamic readonly workspaces as windows drives

PlasticDrive – dynamic readonly workspaces as windows drives

Tuesday, February 17, 2015 Pablo Santos news 5 Comments

UPDATE 2016/05/20: The links to download the Dokan files have been updated.

PlasticDrive is a tool to mount a changeset as a Windows drive and let you quickly browse the code using your favorite tools (Visual Studio, Eclipse, IntelliJ…). Files are downloaded from the server on demand (then cached) so the mount happens immediately, no need to wait for a big update to finish.

Using Plastic Drive

Remark: PlasticDrive is not enabled by default. Check the installation section to learn how to enable it.

Using PlasticDrive is very easy. Just select a changeset menu (whether in the BranchExplorer or in the changesets view), show the changeset and you’ll see something as follows:

Click and in a second the mounted PlasticDrive will show up as the following screencast shows:

Alternatively you can also use PlasticDrive from the command line:

> plasticdrive 66563@codice@localhost:6060

Or specify a label:

> plasticdrive lb:5.4.16.645@codice@localhost:6060

You can use the --drive param to specify a windows drive (otherwise it will autoselect one) and -g to open up the drive automatically on Explorer as it does when invoked from the GUI.

Please notice that a new “tray icon” shows the status of the newly mounted drive:

Right click on it to pop up the context menu to unmount the drive.

Remark: don’t forget to unmounts the drive once you’re done using it.

Why a drive? Isn’t “browse cset enough”?

Normally if you want to browse the code at a certain changeset of label you just go and open “browse repository on this changeset” and then you see a window as follows:

When you do that probably you’re going back in history and studying a bug or trying to understand how a certain piece of code used to work.

You can browse the code and open files one by one… but you can’t go and open the Visual Studio solution that requires access to all the files in the project.

If you need to open Visual Studio (or IntelliJ, Eclipse, whatever IDE) you’ll end up switching your worskspace to the changeset.

And that’s fine since in fact the “switch to branch” operation performs great and downloads files extremely fast.

But what if you’ve changed files on your workspace?

Well, you can shelve them, or you can use a spare workspace for the switch or… well, or you can go and use the new PlasticDrive to perform a quick browse without having to download the entire changeset but only the files you really access.

Readonly workspaces? But you can build code...

Yes, if you go and open a project in Visual Studio inside PlasticDrive you’ll see how VS will start doing a background build in order to be able to do things like “find all references” of a given declaration. In order to do that VStudio needs to write temporary files on disk with the results of the build. It can’t be done on a readonly drive, VStudio would simply fail to build silently and you wouldn’t have “find references”.

That’s why PlasticDrive (unlike the previous version known as glassfs) is able to deal with temporary files.

I mounted my changeset on drive z:, so I can go to the command line and write:

Z:> echo foo > foo.c
Z:> type foo.c
foo

So yes, indeed, PlasticDrive supports temporary files, which is the basic feature required for the builds. You can try to build your code from the drive (there are limitations if you try to overwrite controlled files during the process, since we still don’t allow controlled files to be modified, then not overwritten either).

Isn’t it just a shell extension?

Not really. You can do similar things with shell extensions, like simulating a “virtual drive”, but then they’re not visible from the command line or regular programs.

PlasticDrive implements a virtual file system and mounts it on a Windows drive.

How does PlasticDrive work?

PlasticDrive implements a virtual file system. In fact a user-space file system. The concept is not so extended on Windows but it is on Linux and Mac. It is the very well-known FUSE – Filesystem in Userspace that is packaged in all linux distros.

On Windows we use Dokan to implement a user-space filesystem.

Basically the Dokan library turns a complex task like writing your own filesystem into a very simple one. It handles all the low level details and you just have to implement a very simple interface as follows:

    public interface DokanOperations
    {
        int CreateFile();
        int OpenDirectory();
        int CreateDirectory();
        int Cleanup();
        int CloseFile();
        int ReadFile();
        int WriteFile();
        int FlushFileBuffers();
        int GetFileInformation();
        int FindFiles();
        int SetFileAttributes();
        int SetFileTime();
        int DeleteFile();
        int DeleteDirectory();
        int MoveFile();
        int SetEndOfFile();
        int SetAllocationSize();
        int LockFile();
        int UnlockFile();
        int GetDiskFreeSpace();
        int Unmount();
    }

And Dokan takes care of turning this into a real filesystem.

So, basically each time a file is going to be read, or a directory opened, or a file written, created, moved and so on, your code gets invoked and you handle the operation.

PlasticDrive performs the following operations:

• First it loads the tree of the changeset to mount. The equivalent of a cm ls --tree. It means loading the directory tree of the repo at the given cset, so you know which files will have to be loaded. It is a very, very fast operation and is the first (and only) thing that happens when you invoke PlasticDrive.
• Then when it has to handle a file read operation Plastic Drive will check the previous tree to know if the file is controlled or not. If it is, it will have to go to the server and download the contents. We implemented a local cache in order to avoid re-downloading files again and again from the server. The cache is persistent so once you read a file PlasticDrive won’t download it again, not even in future sessions.
• If a file write operation tries to happen on a controlled file, PlasticDrive will return an error.
• If a file write happens on a non-controlled file then PlasticDrive will handle a “temp cache”. The temp cache will be cleaned up when the drive is unmounted. It basically deals with binaries and object files created as a result of a build.
• If a file read tries to access a temporary file then PlasticDrive will retrieve it from the “temp cache”.

The implementation is not difficult and part of it is about dealing with small optimizations to make the entire thing fast enough. I mean, you can’t open a temp file, read and close for each read operation that an application does, so you must keep a cache of file handles that are available until the file is closed and so on.

The file-cache is stored at C:\Users\\AppData\Local\plastic4\plasticdrive-filecache and you can check how it grows if you’re curious.

The temporary files are deleted when the drive is unmounted but meanwhile they’re here: C:\Users\<your-name>\AppData\Local\Temp\plasticdrive-session4be0b001-090e-4288-964a-aa7de7ec2b64 where the last part of the name is a GUID and it will change from session to session.

How to install Plastic Drive?

First you need to enable PlasticDrive on the GUI (unless you want to invoke it from the CLI) which is done as follows:

• Edit the guiclient.conf file. You can find it at C:\Users\<yourname>\AppData\Local\plastic4\guiclient.conf
• And set this line as follows: <ShowMountPlasticDrive>true</ShowMountPlasticDrive>
• Then restart the GUI.

Then go to the changeset menu and run the “mount”. Since you didn’t install Dokan before you’ll see a dialog as follows:

Read it, since it gives you all the instructions :-). You can CTRL-C to copy the instructions and the URL of the installer to download which is:

https://www.plasticscm.com/externalcontent/dokan/DokanInstall_0.6.0.exe

Download it and install it.

If you’re running a Windows 8 or newer (in my case I’m running Windows 10) you’ll see a warning dialog as follows:

Don’t worry, just click on “rung using compatibility settings” and everything will work.

Once you’re done, go back to Plastic and try again and it will now work :-)

Availability

PlasticDrive has been released in 5.4.16.644

Performance

PlasticDrive is slower than accessing the files on a disk file system. Building the plastic client code is about 3 times slower on PlasticDrive. There are some performance tweaks we can apply in order to speed up the whole thing but being an FS implemented in user mode it will be never as fast as the real disk drive, not at least in the near future.

That being said, it doesn’t mean it is not perfectly usable for what it is intended to do, which is browsing the code without having to update a workspace or perform a full download on a clean one.

Opening a *big* Visual Studio solution is slow the first time since VS reads *every single file* in the projects first. Second time you perform the operation (and from there on) it will be noticeable much faster thanks to the local cache we described above.

Motivation and history

I’ve always been fascinated by dynamic workspaces. ClearCase “dynamic views” used to be great on Unix. The concept of having a workspace where files are loaded on-demand sounds great and, as a developer, playing with filesystems is an attractive challenge.

That’s why we toyed with the concept for a long time. First we called it “glassfs” (it has been around on your Plastic client installer for years, but never properly announced) playing with the idea of “glass makes plastic transparent” and being command line only. We checked several options to implement it, until we found Dokan.

PlasticDrive can’t be compared to ClearCase dynamic views though, at least not yet. The dynamic views were full featured workspaces: you could mount anything and then do checkins and everything. You are not able to checkout or checkin from a PlasticDrive unit, just browse the code and create the temporary files required to compile, but we didn’t add support to actually modify files that are under version control.

The future of PlasticDrive depends on you and whether you find it useful or not. If it ends up being a useful tool, maybe it will make sense to evolve it towards full featured dynamic workspaces.

Wrapping up

PlasticDrive is still an experimental feature so we’re eager to hear from you. Don’t hesitate to send comments here or directly to our support team.

Enjoy!

Pablo Santos

I'm the CTO and Founder at Códice.
I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
And I love simple code. You can reach me at @psluaces.