Azure: рабочая роль записывает в c:\ или локальное хранилище

Я в сомнениях.

У меня есть код, который создает файл "foo.txt", а затем копирует его в большой двоичный объект с помощью UploadFile().
Если я хорошо понимаю лазурную концепцию, я не могу создать этот файл в "c:\"?
Я обязан использовать локальное хранилище в моем ServiceDefinition.csdef и создать его в azureLocalResource.RootPath.

Но есть диск ac:\ для записи (ad:\ для ОС и ae:\ для кода), не так ли?
Для чего он нужен?
Можем ли мы просто использовать его при запуске задача ?

Я спрашиваю, потому что считаю, что этот код работал с c:\ util сегодня.
И я не могу найти, почему аналогичный код не работает в новой рабочей роли.
(Это проблема с файлами и каталогами , а не просто файл)

[Ответ]
Я могу создать этот файл в c:, но настоятельно рекомендуется использовать API локального хранилища, поскольку буква диска не всегда одинакова (например, после перезагрузки).
Локальное хранилище — это просто короткий путь для использования диска для чтения и записи текущего экземпляра.
В конкретном случае задачи запуска мы можем получить доступ к этому хранилищу двумя способами: с помощью azure API в программе/скрипте ac#. (см. эту тему) или с переменными среды (см. эту тему).


azure azure-worker-roles
person Benjamin    schedule 31.07.2012    source источник
comment
Нет необходимости добавлять ответ на ваш вопрос. Вы уже отметили ответ @Sandrino, который люди могут легко найти и проголосовать.   -  person David Makogon    schedule 01.08.2012

Ответы (3)


arrow_upward
8
arrow_downward

Вы не хотите привязывать себя к фиксированным буквам диска. Это правда, что C:\ большую часть времени является диском данных, D:\ большую часть времени является операционной системой, а E:\ большую часть времени находится там, где находится ваш код.

Но рассчитывать на это нельзя, поэтому я и говорю большую часть времени. Как объясняет Райан здесь, возможно, диск вашего приложения изменится с E:\ на F:\ после перезагрузки, то же самое может применяться к вашему диску с данными. Только LocalResource может сказать вам, где вы можете сохранить свои файлы, поэтому я предлагаю вам использовать его.

Если у вас есть задачи запуска, которым необходимо работать с файлами, вам также следует работать с LocalResources. Это возможно с помощью PowerShell: http://blog.smarx.com/posts/using-a-local-storage-resource-from-a-startup-task

person Sandrino Di Mattia    schedule 31.07.2012
comment
Хорошо, я читал книгу, в которой говорилось, что имена определены ... Спасибо за ответ, я был убежден, что локальное хранилище и c: \ совершенно разные, но нет. - person Benjamin; 31.07.2012

arrow_upward
2
arrow_downward

Я бы порекомендовал вам использовать LocalStorage, он предназначен для этой цели, и с помощью API вы можете получить путь/диск вместо жестко закодированной зависимости от определенного местоположения диска. Это также помогает избежать любых проблем с разрешениями, поскольку LocalStorage будет в распоряжении процесса, который выполняет вашу роль.

person BrentDaCodeMonkey    schedule 31.07.2012
comment
На самом деле, я вижу, что после перезагрузки, как сказал Сандрино Ди Маттиа, путь может быть другим, и я зарабатываю катти-исключение ... - person Benjamin; 31.07.2012

arrow_upward
0
arrow_downward

Вы не можете создать свой файл в файловом потоке, а затем загрузить файл? Также рассмотрите последствия запуска рабочей роли в нескольких экземплярах, поскольку ссылка на файл, сохраненный в C:\, может не существовать в зависимости от экземпляра, в котором находится роль. LocalResource лучше всего подходит для этого примера.

Задача запуска обычно используется для выполнения пакетных файлов, поэтому вы потенциально можете запустить сценарий powershell, который загружает текстовый файл с помощью cerebrata. командлеты.

person Christo    schedule 01.08.2012
comment
Я не могу создать свой файл в файловом потоке, потому что использую его с библиотеками (это файл sqlite). Мне не нужно использовать ваш инструмент для моего файла загрузки, потому что он создается в методе Run(), поэтому после задачи запуска. - person Benjamin; 01.08.2012