How to create a dummy file of n size

I am building an app that will download a series of files that comprise a single object. Think of it like a book with chapters. When I load the “book” I want to be able to create a series of dummy files (the chapters) of a certain length that come with the books manifest. As the “chapters” get actually downloaded, I’ll delete the dummy file that represented the chapter.

The idea is that I want to pre-allocate space in the app for the “book” so that its storage footprint for the book is represented in the app even before all the chapters are downloaded.

Any ideas?

I’m going to try restating this in terms that I’m hearing, so you can explain where I’m misinterpreting.

What I’m hearing is that you want to deliberately make your app binary larger, so that people installing it have to wait longer to use it and spend more money to download it.

That is not the case. When a user wants to download a book, comprised of chapters, I want to put dummy files in storage to represent the total size of the book, as if the file were already downloaded (after checking the device for available storage, of course). As the real files are fetched, the dummies are deleted.

The idea is that a book without all its chapters is not a book, so I want to pre-allocate the resources to insure that the device can handle it.

So these dummy files are not going to be included in the /assets directory, but generated by the app after installation? It’s still not something I would do or want an app to do as a user, but if I was going to do it, I would use the writeFile and appendFile methods of the Capacitor Filesystem.

Thanks for the advice.

The use case is actually for an audiobook listener, where we allow the user to download the chapter they are listening to, and fetch the other chapters in the background. We are trying to prevent the scenario where a user might run out of device storage before all the chapters are downloaded.

When a user wants to listen to a book, we don’t want to send them the whole thing up front. That way they can jump right into listening. But the user is, in essence, asking for the whole file. We are looking for a way to spoof a file of a certain size so we can insure the whole thing will eventually fit, without making them wait to download the whole thing first.

What I would do in this situation is optimize for the case where the book is consumed serially, by either aggressively deleting chapter N-1 after chapter N+1 has been fetched, or by having a reaper process that marks old chapters for eviction. Perhaps a user-editable preference with a sensible default of “I would like to allot X amount of storage for books, and if usage hits that cap, start nuking chapters I’ve already consumed”.

Thanks, I’ll consider that. But we really need the entire book to be available for offline listening.

I see this is as a case of the user asking for a 100mb file that we are delivering 10mb at time. But since the entire 100 is needed for it to be complete file, we want to reserve the space up front.

I’m looking for a plugin that will allow us to do that.

Well, as I mentioned before, I think you can do this with Capacitor.

I appreciate your time, but we aren’t using Capacitor and it doesn’t look like appendFile would allow us to specify the file size.

I’m wondering if anybody has used a plugin that I could just say: Make me a file filled with 10mb of zeros. Or something like that.

I think it would. What I would do is to just create a string of “block” size, and then keep appending the same string N times to make a file of size N * block. Analogous to how one would do this with dd on a UNIX system.

Cool. I’ll give that a shot. Thanks again!