very useful

Posted Feb 5, 2015 18:31 UTC (Thu) by flussence (guest, #85566)
In reply to: very useful by nye
Parent article: Inserting a hole into a file

I can already see one immediate use for this: FLAC currently zero-fills a large (about 8KiB) chunk at the start of each file "just in case" you want to add more metadata without reallocating the entire file (which may be hundreds of megabytes). It's large enough to be wasteful for small text edits and too small to be useful for album art; with the filesystem feature it wouldn't need to waste the space at all.

to post comments

very useful

Posted Feb 9, 2015 11:09 UTC (Mon) by nye (subscriber, #51576) [Link]

>with the filesystem feature it wouldn't need to waste the space at all

But FLAC can't know at creation time that the metadata will only ever be edited on a filesystem/OS combo that supports this feature, so it's unlikely to make the assumption that the pre-allocation is not needed.

This is a part of what it means to be too specialised: entirely non-portable, relying on assumptions that can be broken by moving a file even within one system. That doesn't necessarily have to be a bad thing, and it's not that I think this is a *bad* feature, just that in practice it will have to be used transparently and opportunistically as an internal operation, and probably by applications that either don't produce an output file, or already have a final 'rendering' pass or similar, where they can take the opportunity to defragment the result while they're at it.

If it didn't rely on the ability to safely leave small holes in the final files, it would be a lot easier for programs to use the API opportunistically where supported, but since it's not transparent I believe those opportunities will be few and far between.