So I have opened a file with the "open" command and I get a file descriptor. That means I have to use lseek rather than fseek, which is fine by me. But what if I want to know how long the file is or what if I want to know where I am pointing. If I had a FILE*, I could use ftell. But I don't, so what do I use? ltell appears to not exist. Any ideas or alternatives? I need to bounce all over this file and write things, so I'd like to know where I am. Thanks.
VernonDozier 2,218 Posting Expert Featured Poster
Ancient Dragon 5,243 Achieved Level 70 Team Colleague Featured Poster
Why are you using low-level file i/o?? Just use FILE* and all will be ok. The only reason to use open() is when the compiler for the target operating system doesn't have FILE* and associated functions.
But to answer your question, lseek() returns the file offset.
N1GHTS 102 Posting Whiz in Training
Just curious, is there a reason why you need to bounce around in the file? Is it such a large file that it can't be loaded to RAM? Why not use file mapping to map it to a series of struct's or arrays of struct's so you dont ever need to bounce around the file?
sree_ec 10 Junior Poster
Why are you using low-level file i/o?? Just use FILE* and all will be ok. The only reason to use open() is when the compiler for the target operating system doesn't have FILE* and associated functions.
But to answer your question, lseek() returns the file offset.
Although this question is answered, since OP is asking about calculating the file size[ how long the file is], i have a link to share with you.
@AncientDragon, have you experienced anything of that sort as explained in that link. I would like to know your opinion.. I dont have exp in MS technologies... In gcc when i tried, the ftell and fseek all were working as expected..
VernonDozier 2,218 Posting Expert Featured Poster
>> Why are you using low-level file i/o?? Just use FILE* and all will be ok. The only reason to use open() is when the compiler for the target operating system doesn't have FILE* and associated functions.
I inherited a lot of code from the last guy and need to change it. He used file descriptors, so I'm stuck with them or I have to go through all his code and change everything so it takes FILE* parameters. I figured using file descriptors would be easier.
>> But to answer your question, lseek() returns the file offset.
Thanks. Face-->Palm. Didn't really read the lseek description, but instead assumed it returned the same as fseek. We all know what happens when you assume.
>> Just curious, is there a reason why you need to bounce around in the file? Is it such a large file that it can't be loaded to RAM? Why not use file mapping to map it to a series of struct's or arrays of struct's so you dont ever need to bounce around the file?
The files are generally not too big ( afew kilobytes), but potentially could get much bigger. It's embedded program with some fairly limited resources, but enough to handle a buffer containing the whole file, so that is an option.
The files contain records and are searched a lot and inserted and deleted often too, but less frequently. Right now the records are unordered, so it's a pretty brute force method. I'm changing it to an ordered file so I can use a faster binary search and faster insertion. So I want to check how long the file is, get the number of records, bounce to the middle, do the comparison, bounce somewhere else depending on the comparison, etc., till I find the correct spot. Seems easier than reading in the entire file, particularly when the files get bigger.
>> Although this question is answered, since OP is asking about calculating the file size[ how long the file is], i have a link to share with you.
Thanks for sharing the link. It's interesting. I had not heard of that problem before. I don't think it applies to me. I'm using Linux and always reading and writing in binary mode (I guess since I'm using Linux, binary mode is irrelevant).
I was interested in what Salem said here:
http://www.daniweb.com/forums/post778389.html#post778389
Multiple lseeks could be slower that a regular old brute force search. But then there's caching and all that other stuff, plus I'm using nandflash, so that might go out the window.
Ancient Dragon 5,243 Achieved Level 70 Team Colleague Featured Poster
>>@AncientDragon, have you experienced anything of that sort as explained in that link
I have never experienced a problem in MS-Windows with using fseek() and ftell() to get the file size of a binary file. Even if the file had trailing null bytes I don't see how that would invalidate the return value of ftell() because those trailing null bytes are part of the file.
But I suppose there could be some obscure file systems where ftell() might not work. That doesn't mean it should be prohibited for everyone in the world to use it.
There are some embedded systems on which ftell() and other FILE* related functions won't work. I was writing C++ programs for PocketPC os and the Microsoft compiler (eVC++ 3.0) did not support FILE or any of its associated functions. Nor did it support any of the STL classes, such as fstream, iostream, string, etc.
I wrote a small program to find out how VC++ 2010 Express got the file size for _stat() function. It calls FindFirstFile() to get the file's info. I'm not sure how FindFirstFile() gets its information, but most likely by calling other win32 api functions instead of using ftell() or lseek()
Be a part of the DaniWeb community
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.