CODEWITHSUNDEEP
cfileunixio
Bruce Jinru Su
Bruce Jinru Su

Reputation: 189

Unix: write() when offset is larger than size

I have the following code: 

 #include <ctype.h>
    #include <fcntl.h>
    #include <unistd.h>
    #include <sys/types.h>
    #include <sys/stat.h>

    char buf[]="wimpykid";
    char buff[100];
    void pri(int fd);
    int main(){
       int i=0,fd;
       fd=creat("ifile", S_IRUSR|S_IWUSR); pri(fd);
       write(fd, buf, 8); pri(fd);

       lseek(fd, 23, SEEK_CUR);  pri(fd);
       while(buf[i]!='\0'){
        if(i%2)
           buf[i]=toupper(buf[i]);i++;
       }
       write(fd, buf,8);  pri(fd);
    exit(0);
}
//print the current offset
void pri(int fd){
    printf("%d\n", lseek( fd, 0, SEEK_CUR));
}

And the output is 0,8,31,39. After the first write, the offset is now 8. The file has only 8 chars in it, but how could I add 23 to the current offset? If I've done so, when I write another 8 chars to it, where will the 8 chars start at? The output shows the second 8 chars just follow the first 8 directly. I don't quite understand.

Upvotes: 3

Views: 2230

Answers (3)

moooeeeep
moooeeeep

Reputation: 32502

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:

Upvotes: 3

alk
alk

Reputation: 70911

... when I write another 8 chars to it, where will the 8 chars start at?

At position 31, were the code sought to prior to the 2nd write. That is: 0 (initial position) + 8 (after writing 8) + 23 (after seeking 23) = 31

Doing a 

hexdump ifile

gives the content of ifile:

Offet 
in hex  Content in hex
0000000 6977 706d 6b79 6469 0000 0000 0000 0000
0000010 0000 0000 0000 0000 0000 0000 0000 7700
0000020 6d49 7950 694b 0044

Please not that the 23 bytes being sought aren't written to the file until an actual call to write() had been issued.

Upvotes: 0

Rocoder
Rocoder

Reputation: 1103

Try to understand with this

lseek(fd,0,SEEK_CUR) its your current offset value (position = 0)

lseek(fd,1,SEEK_CUR) offset will be incremented to +1 from the current value. (position= 1)

lseek(fd,5,SEEK_CUR) offset will be incremented to +5 from the current value. (position = 6)

and it wont follow the characters after setting the current position to 23. It may display some garbage value there before adding characters.

Upvotes: 0

Related Questions