Краткий / Технический Ответ :
Вероятно, вы можете установить разрешения для определенной папки, используя полное доверие и такты запуска. Тем не менее, вам нужно будет учесть ОС без состояния и изменение букв дисков (возможно, маловероятно) в этом сценарии, что усложнит задачу. Кроме того, локальное хранилище не сохраняется, поэтому вы не сможете гарантировать, что эти данные останутся в случае перезагрузки.
Рекомендация : не пишите по-местному, читайте ниже ...
РЕДАКТИРОВАТЬ: Задумался об этом, и хотя я все еще рекомендую против этого, есть 3-й вариант: вы можете выделить локальное хранилище в конфигурации службы, затем получить доступ к нему из PHP, используя ссылку dll, тогда у вас будет доступ в эту папку. Помните, что локальное хранилище не сохраняется, поэтому оно исчезло во время перезагрузки.
Service Config для локальных:
http://blogs.mscommunity.net/blogs/dadamec/archive/2008/12/11/azure-reading-and-writing-with-localstorage.aspx
Доступ к конфигурации из php:
http://phpazure.codeplex.com/discussions/64334?ProjectName=phpazure
Длинный / подробный ответ:
В Azure вам действительно рекомендуется воспринимать вещи как платформу, а не как «программное обеспечение на сервере». Я имею в виду, что такие идеи, как «записать что-то в локальный файл журнала», несколько несовместимы с «идеей» облака. В зависимости от вашего использования вы можете (и должны) преобразовать этот сценарий для вывода этих данных в какое-либо облачное или внешнее хранилище, а не просто размещать его на диске.
Я бы предложил изменить этот сценарий, чтобы использовать PHP Azure SDK, и записать эти записи журнала в хранилище таблиц или больших двоичных объектов в Azure. Если это звучит хорошо, пожалуйста, предоставьте PHP, и я могу привести точный пример.
Основная причина этого (помимо выдвижения идеи облака) заключается в том, что в Azure нельзя предполагать, что хост-машина («экземпляр роли») будет поддерживать состояние ОС, поэтому в то время как вы можете установить некоторые вещи, такие как разрешения для папок, Вы не можете полагаться на них, придерживающихся этого пути. У вас нет реального способа гарантировать, что эти разрешения не будут сброшены, когда структура должна будет обновить вашу роль и отреагировать на проблему более низкого уровня. Например, отсек для жесткого диска в стойке, где находится текущий экземпляр, может выйти из строя. Если бы сбой был достаточно серьезным, контроллеру Fabric пришлось бы перестроить ваш экземпляр. Когда это происходит, ваш код перемещается на совершенно другой сервер, поэтому возникает необходимость переустановить эти разрешения. Кроме того, в зависимости от изменений, E: \ может внезапно стать диском F: \ или X: \, и вы не узнаете.
Гораздо лучше сделать вид (на некотором уровне), что ваше приложение работает "в Azure", а не "на сервере в Azure", поэтому вы не делаете никаких предположений о среде хостинга. Поэтому все, что вам нужно вне вашего кода (данные, журналы, аудиты и т. Д.), Должно храниться там, где вы можете контролировать (хранилище Azure, внешний вызов и т. Д.)