the low-level APIs involved with file creation. Is there a way to
tell
the file system that you´re creating a file with total size "x" before
any such data is written to it, I mean, as part of the file creation
call?.
Yes.
I mean, it is one thing to create a file with size 0, then start
appending data to it in chunk, than say "hey, I´m creating a
8-gigabytes long file, with name xyz". If the latter exists, I´m
curious if there´s logic at the filesystem level to try to find a
chunk of free space big enough to allocate it (to reduce
fragmentation).
It would almost certainly be the wrong thing to do to try and create an
8GB chunk in one place, at least when considering the entire system
behaviour in the longer term.
downloaded, but I never knew if the file creation call was a single
one or it actually consisted of the file creation call first, and then
a write of the x gigabytes of zeroes...
Depends on the filesystem. Unwritten zero blocks in most file systems are
not stored but are implied by the file length.
I can´t believe that in this day and age (i briefly looked at the
win32 api and it seems there´s no api to create a fixed-size empty
file) there´s no api for this, and that one has to rely on a per-app
implementation (ie filing zeroes).
There is one/
Why am I asking this? because of this lament about the lack of a
"mkfile" command in Linux as there is in Solaris
http://madbodger.livejournal.com/114433.html
So find someone more clueful to read ;). mkfile is a solaris command
hack. You can do the same on any Unix like os with
dd if=/dev/zero of=filename bs=1M count=number-of-megs-you-want
I guess mkfile is someones quick wrapper to hide it, or to use fallocate
Just curious... (I know, you will tell me "it isn´t the job of
a
filesystem to populate the contents of an empty file!). And maybe
you´d be right. Still, I wonder if perhaps fixed-size, empty-file
creation wouldn´t be much faster if it was implemented at the
filesystem level).
Thats why it is.
Alan