Running Visual Sourcesafe under Linux

If you are a Linux developer in a Windows company, and you need to access Visual Sourcesafe repositories over the LAN, take heart: sourcesafe seems to work with Wine. Here are the steps I followed. The skill level required here is fairly high; if you're not an experienced Linux system administrator, you may need to read up on inittab, runlevels, fstab, kernel configuration, wine installation, samba, and all sorts of other arcane stuff.

Step 1: install both Linux and NT on your computer

I used Debian's "Woody" (aka "testing") distribution, as it has up to date Samba support. Create a small fat32 partition for sharing data between NT and Linux (since Linux can't write to ntfs partitions yet). Let's call that your E: drive.

Step 2: install vss on your NT system

Boot your computer in NT, navigate over to the vss directory, and run 'netsetup.exe' there; when it asks you where to install it, choose a directory in your fat32 partition, e.g. E:\vss, so Linux can access it. (You might also be able to get away with mounting your ntfs partition in Linux, but I'm not counting on that yet.) You probably want to install it to a directory without any spaces or punctuation in the name, otherwise you have to do nasty quoting when launching vss via wine.

Step 3: get access to your installation of vss in Linux

You'll need to adjust this depending on where you installed vss.

If you installed it to E:/vss, and E: is the fat32 partition /dev/hda5, create the directory '/dos/e', then add a line like

/dev/hda5 /dos/e vfat ro		0	0
to your /etc/fstab file. Test it with the commands
mount /dos/e
ls -l /dos/e

If you installed it to C:\vss, and C: is the ntfs partition /dev/hda1, create the directory '/dos/c', then add a line like

/dev/hda1 /dos/c ntfs ro,uid=1000		0	0
where 1000 is the uid of this machine's primary user (for some reason, ntfs files are not world readable!?) Test it with the commands
mount /dos/c
ls -l /dos/c

Step 4: get access to the vss repository over the network in Linux

Step 5: install Wine

There are many ways to do this. Some distributions include Wine; Codeweavers makes an easy-install preview version of Wine; and you can always install it from source. For more info, consult your distribution, or see

You have a choice of using a fake windows installation or a real one. I used a fake one; no Windows DLLs were needed at all (except for mfc42.dll).

Make sure you can run a simple Windows program, like notepad.exe.

Step 6: Map a DOS drive to your vss repository

Edit ~/.wine/config to set, say, drive S: to point to your vss repository, e.g.
[Drive S]
"Path" = "/machine/directory"
"Type" = "network"
"Label" = "VSSrepository"
"Filesystem" = "win95"
Make sure you can access the .ini file for the vss repository, e.g. by trying 'wine c:/windows/notepad.exe s:\srcsafe.ini'. If that doesn't work, stop and debug your wine setup and drive mappings.

Step 6: set unix-specific options in vss

Tell VSS that you want all your text files to use LF rather than CRLF as a line terminator by adding the line
EOL = n
in your personal ss.ini file, which is located in /machine/directory/users/username/ss.ini. This is a bit of a kludge, as it affects your Windows vss sessions, too. Anyone know a better way?

Step 7: run vss from Wine

Here's a shell script to run the commandline version of vss:
export ssUser
export ssDir
wine -- /dos/e/vss/win32/ss.exe "$@" -i-

(If you want to run the commandline client without X, here's how: add the lines

and create an alternate wine configuration in ~/.winetty/config, containing the line
"GraphicsDriver" = "ttydrv" 
There ought to be a way to do this without making a whole new wine directory, but I'm too lame to figure it out at the moment.)

And here's one to run the GUI version of vss:

export ssUser
export ssDir
wine -- /dos/e/vss/win32/ssexp.exe "$@"
Put these in ~/bin, chmod +x them, and edit them to reflect your windows username, the location of the vss resository, and the location you installed vss to locally. (You can use either Windows or Unix paths to the vss executables.) Make sure your PATH includes ~/bin.

Unless I've forgotten something, typing

should bring up the gui client.

The first thing I do when using the vss gui is to set the current working directory for the top level folder ($/). Then the gui puts everything in subdirectories of that directory. (See below for an example of how to do this with the commandline client.)

Quirks with both ss.exe and ssexp.exe:

Quirks with ssexp.exe:

Getting a directory recursively

This is truly obscure. To recursively get a source tree using the commandline client ss.exe, you must use -gf, and use the *.* wildcard on the end of a path, else all the files get dumped into the current directory.

For example:

# Get a source tree from SourceSafe.
# -gf Sets Force_Dir to Yes, which causes files to be created according to
# their location in the SourceSafe Hierarchy instead of dumping them all into
# the current directory
# Use *.* wildcard because otherwise files get dumped in the current
# directory!
# -i-y means answer yes to all prompts
set -e -x
export Force_Prj
# Example of nonrecursive get
mkdir -p $HOME/foo1
ss Get "$/foo1/*.*" -gf -i-y -exitcode
# Example of three recursive gets, one with spaces in the top directory name
for dir in foo2 "foo 3" foo4; do
    mkdir $TOP/"$dir"
    ss Get "$/$dir/*.*" -r -gf -i-y -exitcode
Note: it looks like options are order-dependent. Play with the order until it works.

The -gl flag is useful for saying where the files should go:

ss get "$/$dir/*.*" -gl/destination -gf -i-y -r

See MSDN; look especially at Command Line Options and Using the Command Line. Requires Netscape 6, Mozilla, or IE.

Dan Kegel
2 May 2002