When you look at the (printable part of the) file content it may look like the two character sequences that were written directly follow each other:
$ cat ifile
wimpykidwImPyKiD
That is because non-printable characters are not displayed here. You can see them as well, when you have a look at the binary data:
$ hexdump -C ifile
00000000 77 69 6d 70 79 6b 69 64 00 00 00 00 00 00 00 00 |wimpykid........|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 77 |...............w|
00000020 49 6d 50 79 4b 69 44 |ImPyKiD|
00000027
As you can see, there's a number of zero bytes in between the two strings. Where do these zero bytes come from? Have a look at the man-page of the lseek
function:
The
lseek()
function allows the file offset to be set beyond the end of the file (but this does not change the size of the file). If data is later written at this point, subsequent reads of the data in the gap (a "hole") return null bytes ('\0'
) until data is actually written into the gap.
Such files may be implemented as sparse files by the file system.
For reference: