The difference between format and quick format

Having done several installations of Windows over the years and always chosen the “quick format” option over the normal format option (mainly due to the time it takes to do a full format compared to a quick format), I finally looked into what the differences between the two are. Microsoft’s site has a knowledge base article about this very thing.

A full format will wipe the disk, format it and run a check disk to find any bad sectors. A quick format will wipe the disk and format it, but will skip the check disk stage. As it turns out, the check disk stage is the thing that causes a full format to take a lot longer than a quick format.

If formatting a new hard disk, it is probably wise therefore to do a full format to find any sectors that may have been damaged whilst the disk was in transit. If formatting an old disk, it is already in a known state and so a quick format should suffice.


Accessing network file shares from a command prompt

If you’ve ever tried to access a network file share in a command prompt by simply using the cd command, you’ll know that it just complains that “CMD does not support UNC paths as current directories”. Well, there is a way to do it (two in fact):

net use z: \\machine\share
pushd \\machine\share

Both of these approaches map the network share to a local drive letter that you can change to using the cd command.

The first one can be combined with the /user switch to provide additional user details:

net use z: \\machine\share /user:domain\username

The bonus of using the pushd command over the net use command is that it will automatically change the current directory to the mapped drive (which will be the first unused drive letter available in reverse alphabetical order). Also, when finished with the network share, you can use the popd command to remove the mapped drive.


Google page rank and redirection

After reading Jeff Atwood’s recent post about URL rewriting to prevent duplicate URLs, I started to look at my own site’s redirections, specifically with regards to Google’s page rank. The first thing I noticed was that I had two different page ranks for this site.

http://adrianbanks.co.uk had a page rank of 3, whilst http://www.adrianbanks.co.uk had a page rank of zero, even though I’ve never really used the http://adrianbanks.co.uk version of the url.

Jeff’s ISAPI rewrite rules were helpful, but were not going to work on an Apache server. The Apache docs for the URL rewriting engine were very detailed, but a little too verbose to glean which exact rules I needed. Luckily, the Search Engine Promotion Help site has an example of exactly what I was after.

RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\.adrianbanks\.co\.uk [NC]
RewriteCond %{HTTP_HOST} !^report\.adrianbanks\.co\.uk [NC]
RewriteCond %{HTTP_HOST} !^$
RewriteRule ^(.*) http://www.adrianbanks.co.uk/$1 [L,R=301]

The only alteration I had to make was to add in an extra line to stop any subdomains of my site being redirected to the main site.

Now for a quick explanation of how the rules work:

  • The RewriteRule will only run if all of the preceding rewrite conditions (RewriteCond) are true.
  • Line 1 turns on the rewrite engine in Apache.
  • Line 2 will be true if the host url is not www.adrianbanks.co.uk.
  • Line 3 will be true if the host url is not report.adrianbanks.co.uk (this is my alteration for my subdomain).
  • Line 4 will be true if the host url is not empty.

Only if all of these conditions are met will the rule run.

Having made this change, the page rank for http://www.adrianbanks.co.uk has now jumped to up 3.


Ambiguous match found

Whilst porting an ASP.Net application to the .Net 2.0 framework, I came across a spurious error when viewing a few specific pages. The error was occurring during the runtime compilation of these specific aspx pages.

Parser Error

Description: An error occurred during the parsing of a resource required to service this request. Please review the following specific parse error details and modify your source file appropriately.

Parser Error Message: Ambiguous match found.

To make this error more confusing, the error was reported on line 1 of the aspx page which contained nothing more than the page directive tag.

After a bit of searching, I found the cause of the problem. The cause was that there were two member variables declared with names that differed only by case (one was an ASP.Net PlaceHolder control, the other an int). Simply renaming one of the variables solved the compilation error.

Eran Sandler has also encountered this problem, but delves a lot deeper into what is going on.