Question

I am in doubts.

I have a code which create a file “foo.txt” and then copy it to a blob with UploadFile().
If I undesrtand well azure concept I can’t create this file in “c:\” ?
I am obliged to use local storage in my ServiceDefinition.csdef, and create it in azureLocalResource.RootPath.

But there is a c:\ drive for write (a d:\ for the OS and a e:\ for code), isn’t it?
What is it use ?
Can we just use it in the start-up task ?

I ask because I believe that code ran with c:\ util this day.
And I can’t find why a similar code don’t work in a new worker role.
(It is a file and directory issue, not just file)

[Answer]
I can create this file in c: but it is highly recommended to use local storage API, because the drive letter isn’t always the same (after a reboot for example).
Local storage is just a short cut for use the read&write drive of the current instance.
In specific case of startup task, we can acces to this storage by 2 ways : with the azure API in a c# program/script (see this topic) or with environment variables (see this topic).

Answer 1

You don’t want to tie yourself to fixed driveletters. It’s true that C:\ is most of the time the data disk, D:\ is most of the time the OS and E:\ is most of the time where your code resides.

But you can’t count on this, that’s why I say most of the time. Like Ryan explains here, it could be possible that your application disk changes from E:\ to F:\ after a reboot, well the same thing could apply for your data disk. Only the LocalResource can tell you where you can save your files, so I suggest you use it.

If you have startup tasks that need to work with files, you should also work with LocalResources. This is possible by using PowerShell: http://blog.smarx.com/posts/using-a-local-storage-resource-from-a-startup-task