Azure Page Blob обязывает меня изменять размер файла

Я пытаюсь создать Page Blob, потому что в будущем мне понадобится произвольный доступ, хотя я могу загрузить файл, когда я загружаю его, размер будет другим.

Я загружаю "file.docx", а затем загружаю как "file2.docx". Загруженный файл немного больше, на самом деле его размер округлен до размера страницы blob, 512 :) В этом конкретном случае Microsoft Word выдает предупреждение о том, что файл поврежден, но я все еще могу его открыть, и содержимое - это то, что Я ожидал.

Я получил отсюда пример кода: Использование страничных больших двоичных объектов Windows Azure и как эффективно загружать и скачивать страничные большие двоичные объекты. Я проверил код для его загрузки и документацию, и, очевидно, загрузка вашей страницы должна начинаться на границе 512 байт (startOffset% 512 == 0) и заканчиваться на границе 512 байт - 1. Что же происходит, когда я нужно закачать файл, который не выровнен по 512?

Например, если у меня есть файл размером 550 байтов, и я загружаю его и скачиваю, я получу файл размером 1024 байта, верно? Что я должен делать? сохранить исходный размер файла в метаданных или есть способ сделать это правильно? (или пример).

Заранее спасибо.


person vtortola    schedule 18.04.2011    source источник
comment
Из того, что я читал о страничных блобах, я считаю, что функция произвольного доступа больше подходит для сценария, подобного накопителю, когда несколько пользователей записывают разные файлы в один и тот же страничный блоб.   -  person Gaurav Mantri    schedule 18.04.2011
comment
хамм, я вижу, но это все еще проблема, если вы загружаете файл, а вы не можете загрузить 550 байт. Вы должны где-то сохранить исходный размер файла или уметь читать до 0.   -  person vtortola    schedule 18.04.2011
comment
Вы можете захотеть получить занятые диапазоны страниц (msdn.microsoft.com/en -us / library / ee691973.aspx), но даже при этом вам придется прибегать к чтению, пока все не станет 0 байтов. Могу я спросить, в каком случае вы хотите использовать этот текстовый документ (или файл) в качестве страничного BLOB-объекта вместо блочного BLOB-объекта? Вы представляете себе, как несколько пользователей одновременно редактируют один и тот же документ или файл?   -  person Gaurav Mantri    schedule 18.04.2011
comment
И как узнать, что эти байты до 0 не являются реальной информацией? Вот что поразило меня. Пример использования? Конечно: freesoft.org/CIE/RFC/1123/64.htm :)   -  person vtortola    schedule 18.04.2011
comment
И как узнать, что эти байты до 0 не являются реальной информацией? - ›Это именно моя точка зрения. Я полностью согласен с вами, что нельзя полагаться на нули. Я предполагаю, что ваша идея о сохранении фактического размера файла в виде метаданных поможет, но тогда вам нужно будет постоянно обновлять метаданные. Извините, ничем не помог !!   -  person Gaurav Mantri    schedule 18.04.2011
comment
не беспокойтесь, поболтайте о проблеме всегда помогает :) Я пробовал подход с метаданными и помогал: D   -  person vtortola    schedule 18.04.2011
comment
Привет, у меня та же проблема, проблема с разными размерами файлов при создании blob (изображения). Размер загруженного изображения отличается от размера загруженного того же изображения. Поэтому я не могу декодировать изображение с помощью BitmapFactory. Любые идеи?   -  person Omar Rehman    schedule 19.10.2011


Ответы (2)


Да, вы должны «сохранить исходный размер файла в метаданных». Или рассмотрите возможность использования блочных BLOB-объектов.

person Jason Cooke -Microsoft    schedule 18.05.2012

Когда вы спрашиваете о произвольном доступе - вы имеете в виду произвольный доступ к файлу или произвольный доступ к нескольким BLOB-объектам? Ваши описания подразумевают последнее (много передач файлов), то есть небольшие файлы, к которым осуществляется произвольный доступ, и в этом случае блочный BLOB-объект будет делать то, что вам нужно.

Есть ли у вас случай использования случайного поиска в файле? Для этого есть сценарии, но обычно размер файла намного превышает 512 байт.

person Pat Filoteo    schedule 20.06.2011