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 0to 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 0where 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
smbclient '\\machine\directory' -U 'domain\username'If you can't do that, stop; maybe you have problem with Samba.
mkdir /machine mkdir /machine/directory mount -t smbfs -o username='domain\username',password=secret '\\machine\directory' /machine/directoryNote: your password must not contain any commas. Not sure what punctuation smbmount can handle, but commas are right out.
You can try putting a line in /etc/fstab of the form
//machine/directory /machine/directory smb username=domain\user,password=secret,uid=1000 0 0but on my system, that gets executed at boot time before the network is up, and it's kind of nasty to have that password in a publically readable file.
So it's better to create a shell script that is run at boot time, e.g.
#!/bin/sh # Mount/unmount vss directory. case "$1" in start) echo -n "Mounting vss directory" mount -t smbfs -o uid=1000,username='domain\username',password=secret '\\machine\directory' /machine/directory echo "." ;; stop) echo -n "Unmounting vss directory" umount /machine/directory > /dev/null 2>&1 echo "." ;; *) echo "Usage: /etc/init.d/vss start|stop" exit 1 ;; esac exit 0(where 'machine' is the name of the NT file server,
That file should be saved as, say, /etc/init.d/vss, and you should protect it from prying eyes with
chmod 750 /etc/init.d/vssTo cause that script to be invoked automatically, you can call it from /etc/rc.local, or via symlinks, e.g.
ln -s /etc/init.d/vss /etc/rc0.d/K20vss ln -s /etc/init.d/vss /etc/rc1.d/K20vss ln -s /etc/init.d/vss /etc/rc2.d/S20vss ln -s /etc/init.d/vss /etc/rc3.d/S20vss ln -s /etc/init.d/vss /etc/rc5.d/S20vss ln -s /etc/init.d/vss /etc/rc6.d/K20vssThe exact runlevel scripts and how to set them up depend on your distribution; the above is for Debian, which seems to treat runlevels 2 thru 5 as 'full multiuser with graphics and networking'.
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.
[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.
EOL = nin 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?
#!/bin/sh ssUser=username export ssUser ssDir=s:/ 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
WINEPREFIX=~/.winetty export WINEPREFIXand 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:
#!/bin/sh ssUser=username export ssUser ssDir=s:/ 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
ssexpshould 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:
For example:
#!/bin/sh # 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 TOP=$HOME/wheremystufflives Force_Prj=no 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 doneNote: 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
[email protected]
2 May 2002