fseek64()

[jaepi]

Hello there, do you have any idea where to get a good reference for the function fseek64?
Or does anyone of you here knows this function or is there really a fseek64 function? lol. Thanks!

[jaepi]

In addition, what function which is similar to stat that asks for a FILE* fildes rather than int fildes? Thanks!

[Narue]

fseek64 isn't a standard function, so if it exists for your compiler, the documentation will tell you where to find it and how to use it. Have you tried fgetpos and fsetpos? They're designed for large files and the implementation typically uses a 64-bit type as the base for fpos_t.

>what function which is similar to stat that asks for a FILE* fildes rather than int fildes?
There isn't one. If you want that kind of functionality, you need to step outside the standard library.

[GreenDay2001]

I don't know anything about it, infact nothing about 64 bit programming. But a liitle google search helped me to find this.

[vijayan121]

>> what function which is similar to stat that asks for a FILE* fildes rather than int fildes?
the function [B]int fileno(FILE *stream);[/B] is part of both posix and single unix specifications. http://www.opengroup.org/onlinepubs/009695399/functions/fileno.html
this would give the file descriptor using which you can call fstat() which also conforms to posix.

[jaepi]

@Narue - I have heared 'bout fsetpos but I did'nt know that it could deal with larger filetypes. I thought fsetpos64 is used. Thanks! I'll try this instead. Uhmm...have you ever encounter or use fseek64? Which is more preferable between fseek64 and fsetpos?

@vishesh - It says here that fseek64 and even fsetpos64 are new library interfaces? Do have any idea if gcc version 4.0+ supports these functions? Thanks, it really helped me, I'm keeping this document for future references.

@vijayan121 - This is exactly what I need. Thanks!

@all - Thank you very much. :)

[Narue]

>I have heared 'bout fsetpos but I did'nt know that it could deal with larger filetypes.
That's what fsetpos and fgetpos are there for. fseek is limited to the size of a long integer, but because fsetpos and fgetpos rely on an opaque type (fpos_t) for representing the offset, implementations should be using a type that can handle the file size limit of the system. If your compiler doesn't do that, it's safe to assume that the rest of the standard library may be weak as well.

>Which is more preferable between fseek64 and fsetpos?
Between two functions that do the same thing, but with one being standard and the other not, choose the standard function. But make sure that they really do the same thing. If I were to implement fseek64 on my implementation it would look like this:

typedef off64_t fpos_t;

off64_t fseek64 ( FILE *file, off64_t offset, int whence )
{
  return _intern_seek ( stream, offset, whence );
}

Which is identical to fseek because it uses fpos_t internally anyway. In other words, fseek64 would be a fluffy function for compatibility with existing code only. But I can't say how it's implemented on another implementation, so you'll have to do some research.

[jaepi]

I'd rather use fsetpos. Uhmmm, btw, fgetpos and fsetpos come together, right? Or fsetpos may exist without fgetpos (vice-versa).

[Ancient Dragon]

Since this is a C question and not C++ I'm moving it over to the C board.

[Narue]

>Uhmmm, btw, fgetpos and fsetpos come together, right?
They're both standard functions. A hosted compiler is required to provide them.

[jaepi]

> They're both standard functions. A hosted compiler is required to provide them.

I mean when you use it in the code? I tried both (using fsetpos without fgetpos and using the former with the latter).

[Ancient Dragon]

>>I tried both (using fsetpos without fgetpos and using the former with the latter).
Post code, I can't see your monitor from my home so its not possible to help you.

[jaepi]

BOOL CLinux::SetFilePointerEx(HANDLE hFile, LARGE_INTEGER liDistanceToMove, fpos_t lpNewFilePointer, DWORD dwMoveMethod ){
    
if(hFile == NULL){
        cout << "Error SetFilePointerEx, hFile is NULL" << endl;
    }    

fgetpos((FILE*)hFile, &lpNewFilePointer);    
 
    int iCheck = fsetpos((FILE*)hFile, &lpNewFilePointer);
    
    if(iCheck != 0){
        return true;
    }else return false;
}

This is just part of my linux interface which I am currently working on.

[Salem]

> fgetpos((FILE*)hFile, &lpNewFilePointer);
Simply casting things to make the compiler shut up doesn't work.

What is HANDLE (really).
It seems rather too much like a Win32 thing to me.

[jaepi]

I have typdef it in my header as void* since HANDLE is a void*. I have defined all of the Win32 datatypes that are used by their corresponding types.

[Salem]

Lemme guess, you opened the file with CreateFile() ?

Maybe Read The Manual to find out what the corresponding API for 'seek' is to match the method used to open the file in the first place.

[jaepi]

> Lemme guess, you opened the file with CreateFile() ?

I'm making a linux interface, I'm porting win32 apis inorder to fit for the linux platform. CreateFile() is replaced with fopen, fopen64 or open.

[Salem]

So what does your CreateFile() look like then?
How does it turn a FILE* into a HANDLE ?

Since you're using C++, why isn't the actual FILE* maintained as a private member of the class?

[jaepi]

> So what does your CreateFile() look like then?

Since CreateFile can open file, device, disk, blah blah, I directly replaced them in the entire library that I am porting with the corresponding open function in the standard library.

>How does it turn a FILE* into a HANDLE?

This is exactly one of the things that confuses me. I'm not yet that sure of what I did. Let me show you an example.

typedef void* HANDLE;
....
//somewhere in one of my functions
Example_Function(HANDLE* pFile){
  CLinux* lInterface;
  *pFile = NULL;
  FILE* fildes = NULL;
  fpos_t position;

  fildes = fopen64("/home/user/test.iso", "r");
  *pFile = fildes;
  

  lInterface->SetFilePointeEx(*pFile, some_variable, position, FILE_BEGIN);

  //FILE_BEGIN was defined as SEEK_SET
}

I'm sorry if I was not able to give you a desirable answer, but this is what I did. For now, I'm not using the interface that I did, I directly placed or replaced the Win32 apis with it's corresponding standard lib function.