Re: overspecifying raw dev size

In article dg8@cssun.mathcs.emory.edu, johnl@informix.com (Jonathan Leffler) writes: >Any Unix which allows you to seek to a non-existent offset without >reporting an error is broken. Sorry, lseek() modifies the filepointer in the kernel structure. It is only if you try to do some I/O at a non-existant offset that you will get an error. You can write a C program that lseek()'s all over the shop without error (certainly on the few platforms I tried SunOS, SOlaris, HP-UX) > Period. You've been in the US too long Jonathan...;-) > It has been a safe test since the >days of Version 7 Unix (that precedes System III and System V), and I >believe it would be safe on all versions which contain the lseek() system >call -- really early versions of Unix had a seek() system call instead, >which took an int argument for the offset, hence the name lseek() for the >version which takes a long as the offset. What we actually do is an lseek() then a write(). This will verify that space actually exists at that offset. For a cooked file, depending on filesystem type, only disk blocks written to will be asigned in the i-node even if it is after the current end of the file. This generates "holes" of non-existant data in the file. For a raw device we will get an I/O error if we overstep the bounds of the asigned partition. Cosmo