Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

maxBound fileSize is dangerously small on windows #16

Open
joeyh opened this issue Jan 20, 2015 · 1 comment
Open

maxBound fileSize is dangerously small on windows #16

joeyh opened this issue Jan 20, 2015 · 1 comment

Comments

@joeyh
Copy link
Contributor

@joeyh joeyh commented Jan 20, 2015

System.PosixCompat.Files.fileSize is defined to be a FileOffset, just like System.Posix.Files.fileSize.

But, on Windows, maxBound:: FileOffset = 2147483647.
On Linux, it's quite a bit more than this 2 GB!

I have had to avoid using fileSize at al in my program because of this gotcha. (hFileSize doesn't have this problem; it will return the real size of a multi-gb file on Windows).

I don't know how to fix this library. Changing the PosixCompat version of FileStatus to use an Integer would work, but it would break compatability between unix and windows for users of this library. Maybe ghc is at fault for using such a small type for FileOffset on Windows?

@jacobstanley
Copy link
Owner

@jacobstanley jacobstanley commented Jan 21, 2015

I don't want to break compatibility between the unix and windows versions of this library as that is the whole point of the library.

This is a tricky situation, as FileOffset is just a type synonym for COff, which makes sense. COff represents the C type off_t. So it must be in msys/mingw where it defined to be only 32-bits.

This page seems to shed a little bit of light: http://stackoverflow.com/questions/9073667/where-to-find-the-complete-definition-of-off-t-type

Apparently in GCC you can use -D_FILE_OFFSET_BITS=64 in order to get 64-bit off_t and size_t types. However, this would have to be done during compilation of the base library. So we probably need to patch this upstream :/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants