To expand on what Ken said: > And lstat shows: > st_size = 4893 (file size, in bytes) > st_blocks = 0 (blocks allocated for file) > st_flags = 0x20 (user defined flags for file)
I think this may be the result of Dominic Giampaolo hiring on with Apple after Be, Inc. folded. The BFS did something like this. In general, a filesystem will have an inode - an "index node" - that will store the permissions, the precise number of bytes in a file and other info that is not strictly part of the payload data. It will also hold the disk address of the first block of payload data, as well as how many blocks are in a single segment of data. Larger files may have multiple chunks of payload data. Each filesystem type has different notions of how to store large files - indirect blocks, various kinds of trees, linked lists, or maybe it's all one chunk no matter what. But for a very small file, there may be enough space in the inode itself for the payload data. The details as to how that actually works are very much tied up in the specific filesystem types. Some are incapable of it (eg. MS-DOS FAT) some are designed to make harmonious use of it (BeOS BFS). With some it's bolted on as an afterthought (HFS+). I'll send you my bill in the mail. Michael David Crawford, Consulting Software Engineer mdcrawf...@gmail.com http://www.warplife.com/mdc/ Available for Software Development in the Portland, Oregon Metropolitan Area. On Sat, Apr 4, 2015 at 3:21 AM, Ken Thomases <k...@codeweavers.com> wrote: > On Apr 4, 2015, at 4:23 AM, Gerriet M. Denkmann <gerr...@mdenkmann.de> wrote: > >> When I look at " /Library/Dictionaries/Apple >> Dictionary.dictionary/Contents/Info.plist" in Finder, it shows a preview and >> says 5 kB. Ok. >> >> But: Finder → FIle → Get Info says: >> 4,893 bytes (Zero bytes on disk) >> >> And lstat shows: >> st_size = 4893 (file size, in bytes) >> st_blocks = 0 (blocks allocated for file) >> st_flags = 0x20 (user defined flags for file) >> >> /usr/include/sys/stat.h has: >> #define UF_COMPRESSED 0x00000020 /* file is hfs-compressed */ >> >> So: where are these bytes (if not on disk)? >> And if they are really compressed: how much space they take in some unknown >> compressed location? >> >> I am trying to find who or what is taking space on my disk. So given some >> directory, I want to add the disk space of all its files (+ subdirectories). > > In this case, the compressed data was probably small enough to store it in > the file metadata. So, there really are no blocks allocated for the file's > data. > > Do some web searching for "hfs compression" to learn more. > > As far as how you should write a program to compute the space used on disk, I > recommend that you trust NSURLTotalFileAllocatedSizeKey. > > Regards, > Ken > > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/mdcrawford%40gmail.com > > This email sent to mdcrawf...@gmail.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
