Making file of a specific size

[kevinchkin]

Hi Guys,

I am trying to create a file of a specific size. This is the code I was using:

include<iostream>
#include<sys/types.h>
#include<sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
using namespace std;

int main() {
int fd = creat("test.txt", S_IRUSR );
ftruncate(fd,2147483648 );
close(fd);

return 0;

 }

Now when I try to create a file, it gives this warning on compilation
createfile.cc:10: warning: this decimal constant is unsigned only in ISO C90
and it ends up creating a 0 byte file.

Any thoughts?

Thanks

[Packman]

I noticed 2 things:
1.The file size for ftruncate is too large. Try smaller file size.
2. File must not exist. If it already exist it is unchanged. Hope this helps

[kevinchkin]

Well, that's the thing, I actually want to create a large file (Max Size up to 8Gb)

[Disch]

I don't know if it's wise to use ftruncate to extend the filesize. I read that its behavior is implementation dependent when you try that (maybe this is why it's not working?)

To do this, instead I seek to desiredsize-1, then write a single byte. Maybe that will work.

[GenTiradentes]

If I remember right, a single character in a text file is one byte.

There are 1,024 bytes in a kilobyte, 1,024 kilobytes in a megabyte, and so on.

It would be trivial to make a loop to continue appending characters to a file until it matched N characters, where N is the size desired in bytes.

[kevinchkin]

Thanks a lot for the reply guys. Actually, I ended up using linux's dd command to create a file.

[andrei c]

Actually there are 1000 bites in a kilobyte and so on, and sometimes there are 1024 bytes in a kilobyte.It depends on the context and implementation.But normally, because kilo is from the metric system, should have 1000.But this is not always the case.There is a specific scale to refer specifically to base 2 powers, and in that system the equivalent of kilobyte is kibibyte.
See more on wikipedi : en.wikipedia.org/wiki/Kilobyte.

Sorry if it isn't related, not trying to be mean or anything, and definately not trying to be smart, just saying.

[PanGalactic]

Does adding "ull" to the end of "2147483648" ("2147483648ull") fix the problem?

What operating system (and is it 32-bit or 64-bit) and compiler are you using?

If you are compiling a 32-bit executable on Linux/Unix, you may need to pass "-DLARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" to the compiler when compiling your source or use ftruncate64().

[helios]

ftruncate() takes an off_t. Depending on whether the type is signed or unsigned, you will never be able to produce a file larger than 2^31-1 bytes (2 GiB-1 B) or 2^32-1 (4 GiB-1 B). Given that the call is just creating the file, I'm guessing that of_t is signed, and ftruncate() understood that the parameter was negative. It did the closest thing and made the file of size 0.
There's probably a 64-bit equivalent call, even for 32-bit systems. Look it up.



When talking about memory, all prefixes are (or should be) binary. This is convenient because memory sizes tend to be powers of 2. HDD manufacturers took a liking to the decimal SI prefixes because it allows them to put bigger number on the front of the box (1 TB = 1,000,000,000,000 bytes = ~931.32 GiB. It's not unusual to see non-technical people complain about this huge difference when buying HDDs, and think they've been ripped off). Personally, I think it's a completely dishonest practice and it should be abolished.

[PanGalactic]

off_t is always signed. There are functions such as lseek() that return off_t and return -1 to indicate an error.

off_t is 64 bits on my OS. And it's 64 bits on Linux and Solaris even for 32-bit apps when programs are compiled with "-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64".

[kevinchkin]

Hi @helios, @PanGalactic, @andre ci. Thanks for clarifying so many things.

@andre ci: You made a good point about base thing.

@PanGalactic: I would definitely want to try fruncate64() as soon as I will have access to Linux machine (which would be tomorrow)