Scott Hanselman just posted about a case-{in}sensitivity problem he just went through. That reminded me I wanted to talk to you about case-sensitivity in Xceed Zip for .NET and the FileSystem. I remember back in the design days, we debated long and hard on if the FileSystem should be case-sensitive or not. Once we decided to support both, the debate continued about what should be the default behavior.

The conclusions were simple:

1. Immitate by default.
2. Uniformity within single product.
3. Know the differences.

Since System.IO was case-insensitive (and moreover the whole Windows operating system), we had to be case-insensitive by default. Thus, if you have files "first.txt" and "second.TXT" in a folder, the code below will return you two files:

DiskFolder disk = new DiskFolder( @"t:\" );

AbstractFile[] files = disk.GetFiles( false, "*.txt" );

The same way, if you have both files in a zip file, the following code will return both:

ZipArchive zip = new ZipArchive( new DiskFile( @"t:\texts.zip" ) );

AbstractFile[] files = zip.GetFiles( false, "*.txt" );

Now, where it's getting tricky is that you will never have a folder on disk containing both "second.TXT" and "second.txt". The system won't let you create the second one. Thus the following code returns an existing file who's FullName is all lower case, even if the real file has an upper-case extension:

DiskFolder disk = new DiskFolder( @"t:\" );

AbstractFile file1 = disk.GetFile( "second.txt" );

You asked the "Disk" world for file "second.txt", and this world has recognized "second.TXT" as matching your request.

To obey to rule #2, the following code does exactly the same, even though the file stored in the zip file has its extension all upper case:

ZipArchive zip = new ZipArchive( new DiskFile( @"t:\texts.zip" ) );

AbstractFile file2 = zip.GetFile( "second.txt" );

But in a zip file, which can come from a different operating system, you potentially could end up with a zip file containing both. What would happen? I've created such a zip file for our tests, by adding "second.TXT" and "foobar.txt" to a zip file, and hex-editing "foobar" to "second":

second.zip (.23 KB)

When opening this file in WinZip, I can see both files. But when unzipping, it will unzip the first, then try to unzip the second over the first. You just can't unzip both in two separate files. Furthermore, trying to unzip any single one from within the classic view will always unzip both over the same file on disk.

How does Xceed Zip for .NET deal with such zip fles? Try the following code:

ZipArchive zip = new ZipArchive( new DiskFile( @"t:\second.zip" ) );

foreach( AbstractFile file in zip.GetFiles( false ) )

{

  Console.WriteLine( file.FullName );

}

The output is:

\second(1).txt
\second.TXT

Any file that case-insensitively matches another file gets appended a number. This is not a perfect solution, as there is never a perfect solution. To support rule #2, DiskFolder and ZippedFolder instances had to behave the same. This post and the documentation tries to address rule #3

Now, some of you want to always look for exact matches. You simply need to prepend the string mask with a ">", as in "I want a more precise match" ⁽¹⁾. The following code will match a single file:

DiskFolder disk = new DiskFolder( @"t:\" );

AbstractFile[] files = disk.GetFiles( false, ">*.txt" );

The idea with System.String filter parameters is that we replace them with a NameFilter, which is the one responsible for that ">" trick. It only works with methods accepting filters (GetFiles, GetFolders, CopyFilesTo, MoveFilesTo). Methods like GetFile can only return a single instance (actually always returns an instance which may exist or not). Those methods return the single and unique AbstractFile matching your string, based on the world this AbstractFolder belongs to.

⁽¹⁾: We actually debated between using "<" as in "match less items" or ">" as in "a more precise match". I think we ended up tossing a coin! 

I'm currently doing some tests on an alpha version of Xceed FTP for .NET, supporting the Xceed FileSystem. It's so wonderful to be able to manipulate files and folders no mather where they reside. Take this generic directory listing method:

private static void DisplayListing( AbstractFolder folder )

{

  if( !folder.Exists )

  {

    Console.WriteLine( "\n  Folder {0} does not exist.\n", folder.FullName );

  }

  else

  {

    FileSystemItem[] items = folder.GetItems( false );

    long totalSize = 0;

    int fileCount = 0;

    Console.WriteLine( "\n  Folder listing of {0}\n", folder.FullName );

    foreach( FileSystemItem item in items )

    {

      Console.Write( "{0} {1} ", 

        item.LastWriteDateTime.ToShortDateString(),

        item.LastWriteDateTime.ToShortTimeString() );

      AbstractFile file = item as AbstractFile;

      if( file == null )

      {

        Console.Write( "            " );

      }

      else

      {

        Console.Write( "{0,16} ", file.Size.ToString( "N0" ) );

        totalSize += file.Size;

        ++fileCount;

      }

      Console.WriteLine( item.Name );

    }

    int folderCount = items.Length - fileCount;

    Console.WriteLine( "\n  {0} file{1}, {2} folder{3}, {4} bytes\n",

      fileCount.ToString(),

      ( fileCount == 1 ) ? string.Empty : "s",

      folderCount.ToString(),

      ( folderCount == 1 ) ? string.Empty : "s",

      totalSize.ToString() );

  }

}

As you can see, the code does not need to know what exactly is that AbstractFolder. People familiar with Xceed Zip for .NET already know we could call the above method like this:

DiskFolder folder = new DiskFolder( @"C:\Program Files\Microsoft SDKs\WinFX" );

DisplayListing( folder );

And obtain this kind of output:

  Folder listing of C:\Program Files\Microsoft SDKs\WinFX\

 24/11/2004   9:29 AM   <DIR>          bin
 24/11/2004   9:27 AM   <DIR>          Help
 24/11/2004   9:27 AM   <DIR>          License
 24/11/2004   9:27 AM   <DIR>          misc
 24/11/2004   9:29 AM   <DIR>          Setup
 24/11/2004   9:29 AM   <DIR>          VS Install Directory
 11/11/2004   6:03 PM           16,001 ReleaseNotes.htm
 12/01/2005   2:58 PM           17,297 SetEnv.cmd

  2 files, 6 folders, 33298 bytes

Or call the same method like this:

ZippedFolder folder = new ZippedFolder( 
  new DiskFile( @"D:\sample.zip" ), "ContMenuExt" );

DisplayListing( folder );

To get this output:

  Folder listing of \ContMenuExt\

 08/01/2001  11:29 AM            8,091 ContextMenu.cpp
 02/01/2001   4:15 PM            1,005 ContextMenu.h
 08/01/2001  11:32 AM            7,820 ContextMenuExt.cpp
 28/11/2000  11:23 AM              225 ContextMenuExt.def
 02/01/2001   5:02 PM            5,301 ContextMenuExt.dsp
 28/11/2000  11:23 AM              551 ContextMenuExt.dsw
 28/11/2000  11:23 AM              742 ContextMenuExt.h
 02/01/2001   4:12 PM            1,440 ContextMenuExt.rc
 08/01/2001   3:29 PM                2 ReadMe.txt
 02/01/2001   4:12 PM            1,195 resource.h

  10 files, 0 folders, 26372 bytes

With the upcoming version of Xceed FTP for .NET, it won't be more difficult to display the contents of a folder located on an FTP server:

FtpConnectionInfo info = new FtpConnectionInfo( "ftp.microsoft.com" );

FtpFolder folder = new FtpFolder( info );

DisplayListing( folder );

  Folder listing of \

 25/11/2002  12:00 AM   <DIR>          bussys
 21/05/2001  12:00 AM   <DIR>          deskapps
 20/04/2001  12:00 AM   <DIR>          developr
 18/11/2002  12:00 AM   <DIR>          KBHelp
 02/07/2002  12:00 AM   <DIR>          MISC
 16/12/2002  12:00 AM   <DIR>          MISC1
 25/02/2000  12:00 AM   <DIR>          peropsys
 02/01/2001  12:00 AM   <DIR>          Products
 04/04/2003  12:00 AM   <DIR>          PSS
 21/09/2000  12:00 AM   <DIR>          ResKit
 25/02/2000  12:00 AM   <DIR>          Services
 25/02/2000  12:00 AM   <DIR>          Softlib

  0 files, 12 folders, 0 bytes

As a mather of fact, stuff like this already works fine on my machine:

FtpConnectionInfo info = new FtpConnectionInfo( "ftp.cam.org", "***", "***" );

FtpFile ftpFile = new FtpFile( info, @"\pub\Photos.zip" );

if( ftpFile.Exists )

  ftpFile.Delete();

DiskFolder sourceFolder = new DiskFolder( @"E:\My Pictures\Clément\Petites" );

ZipArchive destFolder = new ZipArchive( ftpFile );

sourceFolder.CopyFilesTo( destFolder, true, true );

DisplayListing( destFolder );

DisplayListing( ftpFile.ParentFolder );

This is the output:

  Folder listing of \

 16/09/2004   9:39 AM           11,820 Buzz.jpg
 16/09/2004   9:40 AM           11,143 Chalet - Bercé.jpg
 16/09/2004   9:42 AM           15,749 Clément et Michel.jpg
 16/09/2004   9:43 AM           18,473 Clément et Papa.jpg
 16/09/2004   9:42 AM           15,004 Clément et Valérie.jpg
 14/02/2003   4:17 PM            7,984 clément1.jpg
 14/02/2003   4:18 PM           11,288 clément2.jpg
 14/02/2003   4:18 PM           10,648 clément3.jpg
 11/08/2004   3:25 PM           18,499 Famille.jpg
 11/08/2004   3:23 PM           36,734 Fier.jpg
 16/09/2004   9:40 AM           14,959 Grande discussion.jpg
 16/09/2004   9:41 AM           13,426 Maman et Clément.jpg
 11/08/2004   3:25 PM           24,594 Piscine.jpg

  13 files, 0 folders, 210321 bytes

  Folder listing of \pub\

 27/12/2004  11:06 AM            7,986 Builds du 2004-09-27.htm
 12/01/2005   4:13 PM          208,439 Clement.zip
 27/12/2004  11:06 AM            1,068 FileSystem.txt
 18/01/2005   2:44 PM          208,423 Photos.zip
 27/12/2004  11:06 AM   <DIR>          Second
 27/12/2004  11:06 AM           11,723 VSSWarning.jpg
 27/12/2004  11:06 AM          117,695 appnote.txt
 27/12/2004  11:06 AM               96 vssver.scc

  7 files, 1 folder, 555430 bytes

Am I the only one to find this cool? q

It's been a long time since my last post. I feel like I should post more often, even if the subject may not get your attention. But I have mixed emotions about blogging just for blogging.

Robert Scoble is an hardant promotor of corporate blogging. And prolific. But when he says stuff like "Talk is cheap. Doing is divine." just because he has nothing new to say about Longhorn, he's shooting his foot. How credible is that statement?

I must agree 100% with Frans: While giants are busy fighting on the Desktop Search front, WinFS gets delayed, which should have been the real front. People here at Xceed know what I think about WinFS. While others here were all excited about Avalon and Indigo, I was the first to tell them the real innovation and revolution was WinFS. I'm sorry MS, but WinFS should have been the main Pillar of Longhorn! Instead, WinFS topics on MSDN all start with this remark:

UPDATE: In spite of what may be stated in this content, WinFS is not a feature that will come with the Longhorn Operating System. However, WinFS will be available on the Windows platform at some future date, which is why this content continues to be provided for your information.

Sure, desktop search tools help make my life easier. But it's a temporary solution... And temporary solutions tend to become permanent too easily...

On my TODO list: Post about the WinFS model and its implications on archives like zip files, which are not ready to store data, relationships, and metadata.

I admit, I'm working in zip file compression, and I'm not even using something home made for unzipping zip files I run into. I'm using WinZip's context menu.

Well, I should talk to the past. I've made a man of myself and implemented my own "Unzip Here" context menu, which is using Xceed Zip ActiveX 5.x. Why reinvent the wheel when it works fine? Because it didn't work that fine for me.

How many times have I right-clicked on a zip file, went to the WinZip menu, stared at Extract to here and Extract to d:\someplace\somewhere\zipfilename just to find asking myself: "Does that zip file already contain paths?". If it does, I don't need to create a "zipfilename" subfolder, thus I should select the first menu item. But if it doesn't, I sure don't want all unzipped files to end up in the current folder, thus I want to select the second menu item. I end up opening the zip file just to view file paths.

That's what I just implemented. You right-click on a zip file, you click on Unzip Here, and it will automatically detect if it needs to create a subfolder (using the zip filename) or not, then unzip everything.

I won't go into the full details of how to create a Windows Shell Extension component, the sample is pretty self-explanatory, and the web is filled with tutorials. In short, you:

• Create a new ATL COM AppWizard project (VC++ 6).
• Add a new Simple Object with default names and attributes (make sure not to select "Free Threaded").
• Remove references to the newly created interface, you don't need it. (I left the IDL in there instead of copying the CLSID somewhere else... I'm lazy).
• Remove the type library from the resources and RGS file, you don't need it.
• Implement IShellExtInit and IContextMenu interfaces (see UnzipHereExtension.cpp).
• Add the required registry keys (see "DllRegisterServer" in UnzipHere.cpp).

The heart of the extension resides in IContextMenu::InvokeCommand. Don't forget more than one file can be selected when your context menu gets called.

While debugging, you'll often need to restart the explorer.exe in order to release usage of your DLL. Use the Task Manager's run menu to reload it. If you don't like ending a task via the Task Manager, try this: Start Menu -> Shutdown, press Ctrl-Alt-Shift and click Cancel. The explorer.exe process will end.

On my TODO list:

• Support zip files not ending with the ZIP extension (like self-extracting zip files).
• Implement a "Zip This" menu.
• Add a "File already exists. Do you want to overwrite?" prompt.
• Hide the "aborted" error on non-zip files.

Comments welcomed! Have fun!

When applications like KeyHole will become defacto cartographic applications, someone, somewhere will have the bright idea of putting huge ads on their building' roof.

How about ads on highways? They will have a T form, displaying their contents in front and above!

I can't wait to see the first guy to ask his girlfriend in marriage via KeyHole, spelling "Martha, will you marry me?" on some park's ground...

I've been playing with KeyHole for a few days, and though such tools or web sites have been out there for years, I must admit KeyHole is simply amasing. Its smooth transitions, road map display abilities, sharp and precise images and placeholder sharing possibilities are incredible.

For example, once you have KeyHole installed, I can give you a link to my home, like this one:

Home.kml (.72 KB)

As you can see, both my neighbours have a pool (grin). And then, you could travel up to Xceed's headquarters by clicking on this:

Xceed.kml (.75 KB)

A very neet residential area, surrounded by two golf courses and a huge park, right in the middle of Longueuil. I often compare Longueuil to a mini-Redmond. And finally, how about a higher view of the greater Montreal's south shore:

HighView.kml (2.26 KB)

The next step is building KML files for your clients or invitees that smoothly shows them step by step instructions on how to get from the airport or their house, to your business headquarters or your open house party!

For those playing with the newly released Avalon CTP and Chris Anderson's XamlPad application, and are using other Visual Styles than Windows XP (TGTSoft's StyleXP or patched UXTheme.dll), you can follow these instructions:

• Go in folder "C:\WINDOWS\Resources\Themes\Luna"
• Copy file "PresentationFramework.Luna.NormalColor.FxStyles"
• Go back one folder, then into your current theme's folder
• Paste the copied file
• Rename the file as follows:
• Replace "Luna" with the name of the "msstyles" file
• Replace "NormalColor" with the name of the folder under "Shell" which matches the active color scheme.

For example, I'm running with the CodeOpus theme with the Dusk color scheme:

Within "C:\WINDOWS\Resources\Themes", I copied "Luna\PresentationFramework.Luna.NormalColor.FxStyles" to "CodeOpus\PresentationFramework.CodeOpus.Dusk22.FxStyles". Notice that the color scheme part matches the subfolder name, not the color scheme name ("CodeOpus\Shell\Dusk22" in my case).

BTW, XamlPad's ClickOnce does not work within FireFox. Simply launch it from IE.

So the WinAmp adventure is over? Pfffe! That won't stop me from using WinAmp for listening to di.fm while working! Though I feel WMP10 and the WMA format does a better job at ripping my CDs (quality/size ratio), I've always had a better experience with WinAmp for listening to streamed audio.