Записывает ли «seek» ноль байтов при использовании во вновь созданном двоичном файле?

Question

Я заметил, что когда я делаю что-то вроде этого:

with open('testfile', 'wb') as fl:
    fl.seek(2048*512)
    fl.write(b'aaaaa')

Независимо от моей версии Python, hexdump полученного файла будет иметь нулевые байты в первой части testfile:

$ hexdump -C testfile
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00100000  61 61 61 61 61                                    |aaaaa|
00100005

Это гарантированное, предполагаемое поведение, на которое можно рассчитывать в разных операционных системах?Если да, то где этот факт задокументирован?

Answer 1

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

При поиске позиции после конца файла размер файла увеличивается по мере необходимости с новымбайтов, заполненных 0. В приведенном выше коде вы создаете новый файл и используете seek приращения указателя файла (в python нет указателей , так что это stream position) начальная позиция.Это добавит 0.

В двоичных файлах текущий stream position - это смещение в байтах от начала файла.Если вы увеличите позицию потока, все предыдущие позиции будут заполнены 0 в двоичном файле.

Это в операционных системах;вероятно ДА для всех последних или ОС LTS.Не может быть многообещающим в некоторых устаревших системах.

Документирование положения потока - https://docs.python.org/3/library/io.html#binary-i-o

Answer 2

POSIX гарантирует , что при поиске за концом файла в пробеле останется ноль.Как отметили в комментариях , Windows называет содержимое пробела «неинициализированным»;поскольку проблема в том, что файл будет содержать существующие байты на диске (или из другого процесса), вероятно, будет также надежно получить и 0 там.

Обратите внимание, что для его увеличения необходимо записать файл.Таким образом, разрыв никогда не заканчивается.Чтобы получить дыру в конце, POSIX поставляет ftruncate (что может расширить файл в самом последнем стандарте).В среде, где нет такой функциональности, вы можете искать один байт до конца и записывать 0. Вы также можете искать до конца, записывать, а затем обрезать (сокращать), что может избежать использования дискового пространства в последнем блоке.

Answer 3

Является ли [обнуленные области] предполагаемым поведением, на которое можно рассчитывать в разных операционных системах?Если да, то где этот факт задокументирован?

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

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