Khamis Siksek <[EMAIL PROTECTED]> [2002-08-28 23:36:59 +0300]: > I don't know whether this is a bug or not, but I will describe for you what I have >noticed
Thanks for the report. But it is not a bug. What you are seeing is the difference between disk space used and file size. > There are different outputs for these utilities while I expect the same behavior > $ls -al > $du . -a -b --max-depth=1 > > The difference is in the sizes they show, there is no match between them, for >example I have a file that its size is 201 bytes using ls and 4096 using du . > > If this is not a bug?!! can you explain this behavior for me. The 'ls -l' lists out the size of the file. That is the number of bytes that you would read if you opened the file and read it from beginning to end. This should match what you see with 'wc -c' as well. This is useful when talking about size of files. The 'du' listing is different. It lists out how much disk space you have used. It does not look at sizes of individual files. It instead asks the filesystem how many disk blocks a file is consuming. Therefore du is useful when talking about disk space used. Why are they different? Because no one has ever designed a filesystem that is 100% efficient. Filesystems work in blocks and fragments of blocks. Today fragments are usually 512 bytes. The numbers here are not important and different filesystems do this differently. But the fact that files cannot be stored exactly at their file size but must consume the entire fragment is the important concept. The minimum file non-zero file size is 1 byte but the file still consumes one block which is 512 bytes and the storage ratio is inefficient. But a 8192 size file will consume 16 512 byte fragments and be perfectly efficient. On average over all of the files on your disk things work pretty well. Note that you specifically asked du to print out the result converted to bytes. The natural units for du are the number of 512 byte blocks. But this is not natural for most humans and so there are conversion options such as -b to bytes and -h and -H to larger units. Also consumed but not reported are the associated inode blocks which hold the ownership and mode information of the file. So this as well contributes to the overhead needed when making a filesystem on a disk. Bob _______________________________________________ Bug-fileutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-fileutils