Friday, August 17, 2007

About SourceSafe physical file names and file numbers

If you worked long enough with SourceSafe, you probably heard by now about the physical file names associated with files and projects from a SourceSafe database. The SourceSafe command line ss physical can be used to display the physical file name associated with a logical file or folder from the VSS database.

If you look at the the free SourceSafe tools from the www.ezds.com site you'll find a SSNPL utility whose description says that every SourceSafe file has a number, a physical file name, and a logical file name; ssnpl converts from one to the other.

If you asked yourself why is the number good for, the answer is simple: when storing a reference to a physical file in another database file, VSS will use the file number instead of the physical file name, because it requires less space on disk.

So, the question that remains is how does VSS generate these physical file names, and what is this file number calculated?

Let's start our investigation by creating a new database ("mkss.exe C:\temp\vss"). The database is initially empty, and in the data folder there is only one file, data\a\aaaaaaaa. If you use the "ss.exe physical $/" command you'll find out that AAAAAAAA physical name is used by the database root.

From this MSDN article you'll find that the content of the data\aaaaaaaa.cnt file in the SourceSafe database reflects the physical name of the last file added to the database. Indeed, the initial content of this file is 'AAAAAAAA' - sign that last created file or folder was the database root.

Let's add a file into the database. You'll see that the content of the aaaaaaaa.cnt file is now BAAAAAAA, and SourceSafe has created a new file on disk, data\b\baaaaaaa.

Let's continue adding one-by-one new files into the database and each time look at the content of the aaaaaaaa.cnt to see how the new physical files are named. It's easy to see the files are named BAAAAAAA, CAAAAAAA, DAAAAAAA, etc., each file ending up in the data subfolder identified by the first letter of the filename - (data\b\baaaaaaa, data\c\caaaaaaa, data\d\daaaaaaa), etc. After the last letter of the alphabet is reached (ZAAAAAAA), the filenames wrap back, using the second letter: ABAAAAAA, BBAAAAAA, CBAAAAAAA, etc., with files being created on disk in data\a\abaaaaaaa, data\b\bbaaaaaa, data\c\cbaaaaaa, etc.
So, the SourceSafe naming scheme and location of physical files uses a 26-way hashtable to distribute the files on disk in the a-z subfolders of the data folder.

If you run the SSNPLtool on the files added into the database ("ssnpl.exe $/ C:\temp\vss\data", etc.) you'll see their numbers are incremental: 0 (the database root), then 1, 2, 3, 25, 26, 27, .... etc. for each added file.

It's failry easy now to deduce how the numbering scheme works:

  • each file added into the database gets next available number in sequence: 0, 1, 2, etc.
  • the physical file names are composed of 8 letter characters, using letters A-Z: [L0][L1][L2][L3][L4][L5][L6][L7]
  • the number associated with a file is: (L0 - 'A') + 26 * (L1 -'A') + 26^2 * (L2 - 'A') + 26^3 * (L3 - 'A') + ....

Basically the physical file name is a base-26 representation of the file number, with each base-26-digit represented in A-Z range instead of 0-9A-P.

You should be now able to convert easily between the file numbers and physical file names.

As for the mapping between physical file names and logical paths in the database, that is a bit more complex, so I'll leave it for another time...

Thursday, August 16, 2007

Terminal Service client not using saved credentials

I had this problem for quite a while now, and it finally bothered me enough to go and search for a solution...

I use TS client to connect with smartcard from my home Vista machine to various machines at work through a Terminal Services Gateway.

When I'm connecting to Windows 2003 or Longhorn machines I am only required to input my smartcard pin and this is enough to authenticate me. However, when connecting to my alinc02 Vista machine, things are not that smooth. On this machine, TS asks my smartcard pin, after that it fails with the following message: "Your credentials did not work. Your system administrator does not allow the use of saved credentials to log on to the remote computer because its identity is not fully verified. Please enter new credentials."

'Your credentials did not work. Your system administrator does not allow the use of saved credentials to log on to the remote computer' error message

Of course, after typing my domain user and password the connection succeeded, but why was this dialog necessary?

I've searched the net for the exact error message but I could not find a solution. So I ended up asking the experts...

It turned out that my issue was described in this article from Terminal Services Team Blog, under Scenario 1 (Problems using saved credentials with Vista RDP clients - Connecting from home to a TS server through a TS Gateway server). There was also a solution proposed, too. However, since I was connecting to a Vista machine, I could not use the recommended solution (tsconfig.msc is only available on servers and I could not get to work on my Vista machine the applet copied from a Longhorn machine).

Fortunately there is a solution by altering the TS settings on the client side (this solution is not as secure as using certificates on server for server authentication).
In Vista, the Credential Security Support Provider protocol (CredSSP) adds a couple of group policy settings that are described in detail in MSDN CredSSP group policy settings page.

What I needed to do was:

1. Log on to your local machine as an administrator.
2. Start Group Policy Editor - "gpedit.msc" and accept the UAC prompt.
3. Navigate to "Computer Configuration\Administrative Templates\System\Credentials Delegation".
4. Double-click the "Allow Saved Credentials with NTLM-only Server Authentication" policy.
5. Enable the policy and then click on the "Show" button to get to the server list.
6. Add "TERMSRV/" to the server list, in my case TERMSRV/alinc02.redmond.corp.microsoft.com. Using one wildcard (*) in a name is allowed. For example to enable the setting on all servers in "microsoft.com" domain you can type "TERMSRV/*.microsoft.com".
7. Confirm the changes by clicking on the "OK" button until you return back to the main Group Policy Object Editor dialog.
8. At a command prompt, run "gpupdate" to force the policy to be refreshed immediately on the local machine (although this changed for me after a while)

Modify the 'Allow Saved Credentials with NTLM-only Server Authentication' TS Client group policy

With this policy enabled, the login to my alinc02 machine now requires only the smartcard pin, same as the other machines.

(I was told that if I'm not an admin then I may need to set in the rdp file
enablecredsspsupport:i:0, but this was not necessary in my case - setting it just got rid of the error message and replaced it with a regular Vista logon prompt)

Since we're speaking of group policies, it worth mentioning another setting here, "Allow Delegating Default Credentials", which helps making TS connections to a remote server (in the same domain) without being prompted at all for credentials (current Windows user's credentials are used for the remote server). For more information on this see Mahadev Alladi's blog article which inspired the settings in my case, too.

Wednesday, August 1, 2007

Visual Source Safe 2005 GDR CTP is available

Yesterday Microsoft released the Visual Source Safe 2005 GDR CTP.
(GDR stands for "General Distribution Release" and is a single, cumulative package composed of one or more files used to address a problem in a product - much like a Service Pack. GDRs are intended for public consumption and are made available on external websites)

You can read the KnowledgeBase article detailing the release and download the CTP from this address
http://www.microsoft.com/downloads/details.aspx?FamilyID=faf41edd-924d-449f-aefc-9c86dd499720&displaylang=en

Richard Berg has published in his blog a better list of the bugs fixed with this GDR.

Continuing education

I read today a blog post about the Linux's success in China. Instructive reading, I learned today a couple of new words:

Borg - an "assimilated" Windows user (or drone, with Microsoft probably viewed as Borg Collective)
Maclot - a Mac zealot user (refine definition on google, define:clot)
Freetard - a Linux user or free software zealot (refine definition on google, define:tard)

In this sense I'm a Borg. Prepare to be assimilated, resistance is futile! :-)