I have a question about the fseek() usage in C. I know it can set the offset position of a file descriptor created by fopen(). But can it also set the offset position of a newly created file? To be more specific, can I:
FILE * pFile;
pFile = fopen ( "myfile.txt" , "wb" ); //myfile.txt doesn't exit before
fseek ( pFile , 1024*1024*1024 , SEEK_SET);
fclose(pFile);
Will it create a file with 1 GB size and no content? Or should I at least write something in order to create this 1 GB file?
http://en.cppreference.com/w/c/io/fseek
POSIX allows seeking beyond the existing end of file. If an output is
performed after this seek, any read from the gap will return zero
bytes. Where supported by the filesystem, this creates a sparse file.
you can do this, it create gap file. any read from gap return zero bytes. system do optimize for file system.
Related
I am simulating multithreads file downloading. My strategy is in each thread would receive small file pieces( each file piece has piece_length and piece_size and start_writing_pos )
And then each thread writes to the same buffer. How do I realize it ? Do I have to worry about collisions ?
//=================== follow up ============//
so I write a small demo as follows:
#include <stdio.h>
int main(){
char* tempfilePath = "./testing";
FILE *fp;
fp = fopen(tempfilePath,"w+");//w+: for reading and writing
fseek( fp, 9, SEEK_SET);//starting in 10-th bytes
fwrite("----------",sizeof(char), 10, fp);
fclose(fp);
}
And before execution I let content in "./testing" to be "XXXXXXXXXXXXXXXXXXX", after I do the above I get "^#^#^#^#^#^#^#^#^#----------" I wonder where is the problem then ....
Do what most torrent clients do. Create a file with the final size having an extension .part. Then allocate non-overlapping parts of the file to each thread, who shall have their own file-descriptors. Thus collisions are avoided. Rename to final name when finished.
Unless you want to use a mutex, you can't use fwrite(). FILE *-based IO using fopen(), fwrite(), and all related functions simply isn't reentrant - the FILE uses a SINGLE buffer., a SINGLE offset, etc.
You can't even use open() and lseek()/write() - multiple threads will interfere with each other, modifying the one offset an open file descriptor has.
Use open() to open the file, and use pwrite() to write data to exact offsets.
pwrite() man page:
pwrite() writes up to count bytes from the buffer starting at buf to
the file descriptor fd at offset offset. The file offset is not
changed.
I have opened one file with following way:
fp = fopen("some.txt","r");
Now in this file the 1st some bytes lets say 40 bytes are unnecessary junk of data so I want to remove them. But I cannot delete that data from that file, modify or
create duplicates of that file without that unnecessary data.
So I want to create another dummy FILE pointer which points to the file and when I pass this dummy pointer to any another function that does the following operation:
fseek ( dummy file pointer , 0 , SEEK_SET );
then it should set the file pointer at 40th position in my some.txt.
But the function accepts a file descriptor so i need to pass a file descriptor which will treat the file as those first 40 bytes were never in the file.
In short that dummy descriptor should treat the file as those 40 bytes were not in that file and all positioning operations should be with respect to that 40th byte counting as the is 1st byte.
Easy.
#define CHAR_8_BIT (0)
#define CHAR_16_BIT (1)
#define BIT_WIDTH (CHAR_8_BIT)
#define OFFSET (40)
FILE* fp = fopen("some.txt","r");
FILE* dummy = NULL;
#if (BIT_WIDTH == CHAR_8_BIT)
dummy = fseek (fp, OFFSET*sizeof(char), SEEK_SET);
#else
dummy = fseek (fp, OFFSET*sizeof(wchar_t), SEEK_SET);
#endif
The SEEK_SET macro indicates beginning of file, and depending on whether you are using 8-bit characters (ASCI) or 16-bit characters (eg: UNICODE) you will step 40 CHARACTERS forward from the beginning of your file pointer, and assign that pointer/address to dummy.
Good luck!
These links will likely be helpful as well:
char vs wchar_t
http://www.cplusplus.com/reference/clibrary/cstdio/fseek/
If you want, you can just convert a file descriptor to a file pointer via the fdopen() call.
http://linux.die.net/man/3/fdopen
fseek ( dummy file pointer , 0 , SEEK_SET );
In short that dummy pointer should treat the file as there is no that 40 byte in that file and all position should be with respect to that 40th byte as counting as it is 1st byte.
You have conflicting requirements, you cannot do this with the C API.
SEEK_SET always refers to the absolute position in the file, which means if you want that command to work, you have to modify the file and remove the junk.
On linux you could write a FUSE driver that would present the file like it was starting from the 40th byte, but that's a lot of work. I'm only mentioned this because it's possible to solve the problem you've created, but it would be quite silly to actually do this.
The simplest thing of course would be just to abandon this emulating layer idea you're looking for, and write code that can handle that extra header junk.
If you want to remove the first 40 bytes of a file on the disk without creating another file, then you can copy the content from the 41th byte and onwards into a buffer, then write it back at offset -40. Then use ftruncate (a POSIX library in unistd.h) to truncate at (filesize - 40) offset.
I wrote a small code with what i understood from your question.
#include<stdio.h>
void readIt(FILE *afp)
{
char mystr[100];
while ( fgets (mystr , 100 , afp) != NULL )
puts (mystr);
}
int main()
{
FILE * dfp = NULL;
FILE * fp = fopen("h4.sql","r");
if(fp != NULL)
{
fseek(fp,10,SEEK_SET);
dfp = fp;
readIt(dfp);
fclose(fp);
}
}
The readIt() is reading the file from the 11 byte.
Is this what you are expecting or something else?
I haven't actually tried this, but I think you should be able to use mmap (with the MAP_SHARED option) to get your file mapped into your address space, and then fmemopen to get a FILE* that refers to all but the first 40 bytes of that buffer.
This gives you a FILE* (as you describe in the body of your question), but I believe not a file descriptor (as in the title and elsewhere in the question). The two are not the same, and AFAIK the FILE* created with fmemopen does not have an associated file descriptor.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How do you determine the size of a file in C?
How can I obtain a file's size in C? I opened with an application written in C. I would like to know the size, because I want to put the content of the loaded file into a string, which I alloc using malloc(). Just writing malloc(10000*sizeof(char)
You can use the fseek and ftell functions:
FILE* f = fopen("try.txt","rb");
fseek(f, 0, SEEK_END);
printf("size of the file is %ld", ftell(f));
for file size, stat, lstat or fstat will be the right choice.
pleas check stat
int Get_Size( string path )
{
FILE *pFile = NULL;
// get the file stream
fopen_s( &pFile, path.c_str(), "rb" );
// set the file pointer to end of file
fseek( pFile, 0, SEEK_END );
// get the file size
int Size = ftell( pFile );
// return the file pointer to begin of file if you want to read it
rewind( pFile );
// close stream and release buffer
fclose( pFile );
return Size;
}
more answers cplusplus.com
You can position yourself at the end of the file with fseek and use ftell() for that:
FILE *fd;
fd = fopen("filename.txt","rb");
fseek ( fd, 0 , SEEK_END );
int fileSize = ftell(fd);
filesize will contain the size in Bytes.
gekod
I thought there was a standard C function for this, but I couldn't find it.
If your file size is limited, you can use the solution proposed by izomorphius.
If your file can be larger than 2GB then you can use the _filelengthi64 function (see http://msdn.microsoft.com/en-us/library/dfbc2kec(v=vs.80).aspx). Unfortunately, this is a Microsoft/Windows function so it's probably not available for other platforms (although you will probably find similar functions on other platforms).
EDIT: Look at afge2's answer for the standard C function. Unfortunately, I think this is still limited to 2GB.
Here is the problem: I have to change header of WAVE file, to be exact I have to change ChunkSize and SubChunk2Size. The problem is that those values use 4bytes but it seemt that using fwrite i overwrite 8 bytes:
the original:
RIFFđ WAVEfmt
edited:
RIFF(} } fmt
code:
FILE *nova;
nova=fopen ( "nova.wav", "wb" );
fseek ( nova, 4, SEEK_SET );
fwrite ( &brojacC,4,1,nova );
fseek ( zvuk, 44, SEEK_SET );
fwrite ( &brojacCS2,4,1,nova );
In edited file WAVE is overwritten. Something went wrong because I started at 4th byte and wrote 4 bytes and WAVE starts at 8th byte.
I hope I was at least a bit clear. Can this be done in some other way?
Well, according to my man fopen output:
r Open text file for reading. The stream is positioned at the
beginning of the file.
r+ Open for reading and writing. The stream is positioned at the
beginning of the file.
w Truncate file to zero length or create text file for writing.
The stream is positioned at the beginning of the file.
w+ Open for reading and writing. The file is created if it does
not exist, otherwise it is truncated. The stream is positioned
at the beginning of the file.
a Open for appending (writing at end of file). The file is cre‐
ated if it does not exist. The stream is positioned at the end
of the file.
a+ Open for reading and appending (writing at end of file). The
file is created if it does not exist. The initial file position
for reading is at the beginning of the file, but output is
always appended to the end of the file.
That being said, I would definitely go forfopen("nova.wav", "r+b"), as w seems to truncate the file, and you're reading before writing, while a appends to the end of the file, and you want to rewrite part of the file.
This code has at least one bug on every line shown.
FILE *nova;
It is easier to get the error handling right if you do this sort of thing with open, write, and lseek rather than fopen, fwrite, and fseek.
nova=fopen ( "nova.wav", "wb" );
The second string should be "r+b" instead of "wb" so you don't truncate the file. You need to check for errors.
fseek ( nova, 4, SEEK_SET );
You need to check for errors.
fwrite ( &brojacC,4,1,nova );
fwrite should always be called with second argument 1 and third argument equal to the size of the data to be written; otherwise it is impossible to recover from short writes. You need to check for short writes and write errors.
You don't show the code that initializes brojacC so I can't assess whether you have any endianness or structure-padding problems, but I bet you do.
fseek ( zvuk, 44, SEEK_SET );
This operates on the unrelated file handle zvuk rather than nova. And you need to check for errors.
fwrite ( &brojacCS2,4,1,nova );
Since the fseek call on the previous line was applied to zvuk, this writes at offset 4+4=8, not offset 44 as was intended. All the comments on the previous fwrite line also apply to this line. (Psst: You need to check for errors.)
Inconsistent spacing around commas, by the way, invites the gods to strike you with lightning. So does putting spaces on the inside of your parentheses.
I wish to open a file using the "a+b" mode, i.e. if it does not exist it is created automatically, but if it does I don't want to overwrite it. I want to be able to read and write to the file.
The file is binary, and I want to save records of a specific struct in it. So I want to do fseek() to the record I want and then save the record using fwrite().
The code looks as follows (MyRecord is a typedef to a struct, while FILENAME is a #define to the file's name):
int saveRecord(MyRecord *pRecord, int pos)
{
FILE* file = fopen(FILENAME, "a+b");
if (file == NULL)
{
printf("Unable to open file %s\n", FILENAME);
return 0;
}
fseek(file, pos * sizeof(MyRecord), SEEK_SET);
fwrite(pRecord, sizeof(MyRecord), 1, file);
fclose(file);
return 1;
}
However this code just appends the record to the end of the file, even if I set pos to 0. Why isn't fseek() with SEEK_SET working in append mode?
I know I can simply open it with "r+b" and if it fails open it with "wb", but I want to know why this doesn't work and why fseek() with SEEK_SET is leaving the file pointer at the end. Any references to places where this behaviour is documented appreciated (because I couldn't find any, or I am using the wrong keywords).
That's because in a mode, writing to the FILE* always appends to the end. fseek only sets the read pointer in this mode. This is documented in the C standard, 7.19.5.3 fopen:
Opening a file with append mode ('a' as the first character in the mode argument)
causes all subsequent writes to the file to be forced to the then current end-of-file,
regardless of intervening calls to the fseek function.
Plain C does not have any sane way to achieve what you want. If you're on a POSIX system or anything remotely close, you can use fd=open(FILENAME, O_CREAT|O_RDRW, 0666) and then fdopen(fd, "rb+").
Edit: Another thing you could try, with plain C:
f = fopen(FILENAME, "a+b");
if (!f) /* ... */
tmp = freopen(0, "r+b", f);
if (tmp) f = tmp;
else /* ... */
Use "r+b" mode and fallback to "w+b" if it fails.
The "a+b" mode, allows you to read and append; the "r+b" allows random read and write.
The documentation for fopen describes how the file behaves with the different modes.