0

I'm using the function

int open (const char *filename, int flags[, mode_t mode])

in my code to open files.

    file->fd = open(filename, O_RDWR | O_BINARY);
    if (file->fd == -1) {
        perror("cannot open file");
        return -1;
    }

My code is running well on GNU/linux (64bit) but on Windows (64bit) I can't open file larger than 4Go. I would understand I have this kind of problem on 32bit systems, but I do not understand why it is the case on Windows 64bit. I've read documentation and there is the function open64. However this function is dedicated to 32bit systems which is not my case (Don't care about 32bits systems).

I don't think this topic is a doublon because all the topics I've read explain how to use the macros -D_FILE_OFFSET_BITS=64 or -D_LARGEFILE_SOURCE=1, but again it is for 32bit system. I've also read that there's a flag: O_LARGEFILE to do it. But apparently it is a bad practice as it should be done automatically.

I'm stuck and I do not want to change all my code to use fopen, so if anyone has a solution for opening large file with open in Windows it could be great.

lock
  • 411
  • 4
  • 15
  • On Windows, are you using Cygwin or similar POSIX compatibility layer? If you do, is it a 64-bit install of it? – Some programmer dude Sep 15 '17 at 07:36
  • I'm not the one compiling the software on Windows but I believe it is done with mingw 64bits. – lock Sep 15 '17 at 07:38
  • MinGW is nothing more than the GCC compiler ported to Windows, it does not have a POSIX compatibility layer (and [`open`](http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html) is a POSIX function, it's not standard in Windows). You should probably get more information from the person attempting to build your application on Windows. – Some programmer dude Sep 15 '17 at 07:40
  • The software is compiling very well. And it is running too. – lock Sep 15 '17 at 07:42
  • By the way. On linux I'm using gcc and it works well. The same on OS X. Only Windows gives this issue. – lock Sep 15 '17 at 08:05
  • 2
    Both Linux and macOS are POSIX platforms, which have a native `open` function. Windows does *not* have a native `open` function. Windows do have the somewhat compatible [`_open`](https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/open-wopen) function, and there are of course POSIX compatibility systems like [Cygwin](https://www.cygwin.com/). Without knowing what is used on the Windows system, there's no way of answering this, it's to broad. ***You*** need to get more information from the person building this on Windows, and edit your question to include that information. – Some programmer dude Sep 15 '17 at 08:17
  • Your explanation is great. Thank you. I've read this: https://msdn.microsoft.com/en-us/library/z0kc8e3z.aspx I think that I could use `_wopen` in windows case. – lock Sep 15 '17 at 08:23
  • `-D_FILE_OFFSET_BITS=64` etc are specific to glibc. No Windows environment uses glibc. – o11c Sep 16 '17 at 18:07
  • Note that even though the Windows *OS* is 64-bit, a lot of programs (and development environments) are still 32-bit because of inertia. – o11c Sep 16 '17 at 18:08

1 Answers1

1

I may have found a solution. Indeed Windows does not have POSIX compatibility and this is the problem (as mentionned by @Some programmer dude. But the open function does the job. The problem comes from lseek. I need to do something like that:

#ifdef WIN32
#include <io.h>
#endif
...
#ifdef WIN32
#define lseek64 _lseeki64
#else
#define lseek64 lseek
#endif

Then, the type of lseek use to be off_t. But this type is also POSIX standard. So, the last thing I did is to replace all the off_t by int64_t.

It is now working very well.

lock
  • 411
  • 4
  • 15