• Z: the ROM drive where the firmware resides
• C: the internal flash memory drive (aka. phone memory)
• D: the RAM mapped drive used as a temporary fast access file cache
• E: the mass storage drive, usually a removable memory card but on some devices replaced by an internal flash drive or even HDD.

Out of the four drives two are usually ignored, one for being read-only and the other one for being volatile. So the developers are focusing on the C: and E: drives, the ones used for storing application's files, the ones where the user stores the mp3 collection that the application needs to scan for.

The N96 phone was announced some long time ago but I have not seen many comments regarding the fact that this is the first phone to have both internal mass storage drive (16GB flash) and support for removable SD cards (up to 8GB). Good news for the end-user but how is this feature seen from the developer perspective? Is your application ready to handle one more drive?

But wait, there's more. N96 is a S60 3rd Edition phone, supporting Feature Pack 2. That means it supports another nice but rather ignored feature that this platform release brings: Remote drives, the network drives based on the WebDav protocol. More drives for your applications to handle.

So, how should an application handle all these drives? Well, to start with, one should simply stop assuming and start querying. How many drives does the device have? What type of drives are they? Can I use them? The answer to all this question is dynamic and so should be the code that handles it. Remove all the hardcoded paths, all predefined drive enumerations.

The APIs needed for adding support for multiple drives to your application are now available as a dedicated SDK plug-in. Documentation and example application are included so … Happy coding! ;)