Just purchased a Toshiba USB 2.0 4GB flash drive. I dragged a 11.5MB font application to it. When it appeared in the flash drive it was at 24.8MB…..I have never owned a flash drive before and was wondering if I did something wrong?

At first glance I'd think of allocation block size of the flash drive (32-128KB), and the number of constituent files in your font application package (Right- or Control-click on your font app, and select Show Package Contents to view). If both are rather large, the inherent inefficient use of storage space could explain the file size discrepancy.

In addition, drive format type used (FAT16-32-64) affects bloat too, but decreasingly so when going from FAT16 to FAT64. For example, if the drive is formatted FAT16 now, you could improve things by reformatting to FAT32.

Thanks ..I do not know how to reformat,but I did notice I can compress the file at smaller MB….could this work for a back up? As far as block size goes I am at a loss. Again tks for the reply

The allocation blocks of storage devices like hard disks and flash drives are the smallest storage units available. It's like rooms in a hotel: you pay by the room (one or more), not by part of a room. The bigger the room, the more people you can accommodate, but also the more space you waste if you're just by yourself. The allocation blocks on flash drives are the size of ball rooms, and quite wasteful for single travelers like the small files in an application package. A traveling family (like a large file) can split over several rooms, and thereby use the equivalent allocation blocks more efficiently. The critical variable here is not size per se, but the fact that we're dealing with a single file.

And that's what could be going on here: your font app (not a single file but a 'package' of files) probably consists of many small sized files that each get allocated a (wastefully) large room, because that's the only size available. The net effect of this is that the total space allocated exceeds that optimally required by quite a bit, in this case by about a factor 2. If allocation blocks would be smaller (like the 4K or so on your HD), or the file sizes larger (the size of the allocation blocks or multiples of those) this waste would be much less. The latter is achieved by compressing an application package so that it appears as a single large file, exactly the solution you propose. If all this is correct, that solution should work better. If so, please let us know!

Thanks for the great explanation..I compressed the Font application and it became a zip archive file at 6MB which I dragged to my flash drive. When I doubled click the zip file, it opened the Font application though it was at the original 24.8MB. I trust this is what you wanted to know. Thanks again
J

If the block size is 8mb that would make sense but that sure sounds like a large block size.

It's easy to tell the block size, just open something like text edit and save a new empty document to the drive to check.

Then go to it in finder. if you select and get info it should say how big the file is, it should be a few kb or so. But in finder's file list, it should indicate the file size as something larger, and that's the block size.

It's hard to chew up a lot of space due to this overhead unless you have a lot of files. Statistically speaking, each file consumes 1/2 the block size (on average) more space on the drive than the file's size. If you copy say, an application package, to a drive, that package contains many many small hidden files inside the package, each of which consumes this overhead separately, and it all adds up.

But if you were copying a single file (font file you said?) and it wasn't a package, that shouldn't be an issue. I just looked in /Library/Fonts, and all the various font files don't appear to be packages so I can't see where a single font file would consume a lot of overhead. (this overhead is aka "slack space" if you care to know)

Smaller volumes usually have smaller block sizes, because the reason for the block size is they try to limit the TOTAL number of blocks on the drive, and so the larger the drive, the larger the blocks need to be. So for example, copying the contents of a CD or DVD to your hard drive can result in a lot more space being taken on your hard drive due to the difference in block size. between a 600mb and 500gb drive. When copying to smaller volumes, such as flash drives, usually LESS space is taken up. This is because the block size is smaller, allowing for a percentage drop in slack space used. Basically a file that was one byte in size goes from taking up one block on the big drive, to one block on the small drive, which may be the difference between say a 50k and a 4k block.

Although... looking at my home folder here, my block size on this 500gb drive is only 4k. Must be something to do with HFS+. I remember at one point in the (distant? OS 9?) past my block size was 56k. The partition type can factor into what you can expect for block sizes, so if your flash drive is fat-32 or fat-16 it may be quite different. HFS (not HFS+) may have a max block count of say, 2^21 addressable blocks per volume. If I had a 120gb drive at the time, that's what it would be. Maybe someone else here has more current information on this.

The difference between FAT16 and FAT32 is similar to that between Apple's HFS and HFS+. FAT16 can only handle 65,517 allocation blocks on a volume, and consequently they get larger as the volume size increases. For a 4 GB FAT16 volume, allocation block size comes out to 64 KB. FAT32 can handle over a quarter billion blocks, which allows for a block size of 4KB for a drive up to 1TB (or proportionally smaller for smaller drives).

Since it's new it's likely that your flash drive is FAT32 formatted, which you can verify by selecting it in Disk Utility or under the USB tab (>File System) of Apple's System Profiler (Apple menu>About This Mac>More Info...). If the format is FAT32, your size discrepancy must be based on a large number of small files contained in the font app package in question.
Should it be FAT16 after all, you could reformat with Disk Utility by selecting "MS-DOS File System" (which is FAT32).

It is FAT32..I guess I did the proper thing in compressing the file?
thanks again to you and virtual1 for your help

Jay-bird,

Does your Toshiba USB 2.0 4GB flash drive need to be used with a computer or volume running Microsoft Windows?

I'm not sure how to find that out. The package says TransMemory for use with notebook and desktop computers,as you can see I use it on my imac.

Nothing you did while using your new flash drive was wrong. You simply ran into a peculiarity of the file system used on it, brought about by the type of application ('package') you copied onto it.

Your use of a compressed version of that application minimizes the storage inefficiency of multiple small files making up that font app by packing them in a single compressed archive. You can compare the size of that archive on your hard drive (6MB) with that on the flash drive (?MB), and I expect those two values to be much closer than those of the uncompressed app (11.5MB vs. 24.8MB).

Btw, there's no reason to compress files that take up more space on your flash drive compared to your HD other than that you need the space compression frees up. I only mentioned it as a test of my explanation of the size discrepancy.

Since it's new it's likely that your flash drive is FAT32 formatted,

I don't know, I keep seeing new flash drives formatted FAT16...

maybe just old stock, but more likely they just plain don't care