Fabio Miranda Hamburger wrote: > >> I am curious about the mismatch between du and ls. Apparently, du reports > >> amount of 512 or 1024-K blocks, and ls lists the absolute value. > > > > du reports the amount of disk space which the file uses, while ls > > reports the amount of data which it contains. > > > >> But, why in some cases, a 1100 bytes file is reported by du as 4 x 512 > >> bytes instead of 3 x 512bytes > > > > Because the file occupies 2 x 1024-byte blocks. > > > >> I note both use fstat(). > > > > stat(), fstat() etc, and thus du, report disk usage in multiples of > > 512-byte blocks, as that was the block size on the earliest Unix > > systems. The actual block size depends upon the filesystem. > > > > The st_size field indicates the actual size of the file (i.e. the > > number of bytes which it contains); this is the value reported by ls. > > > > The st_blocks field returns the disk usage in multiples of 512 bytes; > > this is the value reported by du. > > > > Note that the actual size of the file can be more than 512 * st_blocks > > bytes if the file contains "holes". These are blocks which are > > implicitly filled with zeros when the file is enlarged by lseek(), > > ftruncate() etc, and aren't actually stored on disk. > > Glynn, why lseek() will fill space with zeros if it's placed in a position > beyond file limit itself? To provide to the application a fixed size of > data for one purpose and so on. > > Example, an application will use first 1025k of a file for something, then > the next 2048 fo another, is this the intention of lseek() ? An application may want to write fixed-sized records, so that they can be accessed in an arbitrary order, using lseek() to locate a specific record. -- Glynn Clements <glynn@xxxxxxxxxxxxxxxxxx> - To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
