error opening a file pointer?!

[Martin]

Hi,

I am trying to write a quick program to access data from a large file
(3238400000), so I intended to use fseek to move around it. However I
can't even open a file pointer and for the life of me I can't spot the
problem. I end up with NULL being returned by fopen! Any thoughts
would be appreciated.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char **argv)
{
FILE *f;
char fn[2000];

strcpy(fn,"/some_place/somefile.bin");

if ((f = fopen(fn, "rb")) == NULL) {
fprintf(stderr, "%s: couldn't open file %s for read\n", argv
[0], fn);
exit(1)
}

fclose(f);

return (0);
}

The only thing I could think of was that perhaps it was because the
file wasn't in my data area, but I checked the permissions and they
seemed ok? And I copied the file local to my directory and that didn't
change things.

ls -l /some_file/someplace.bin
-rw-r----- 1 someone global 3238400000 Jun 4 19:13 /some_file/
someplace.bin

Many thanks,

Martin

 

[Don Morris]

Hi,

I am trying to write a quick program to access data from a large file
(3238400000), so I intended to use fseek to move around it. However I
can't even open a file pointer and for the life of me I can't spot the
problem. I end up with NULL being returned by fopen! Any thoughts
would be appreciated.

Printing the error code may help here to narrow down the
reason (correlate the error with the reasons for error in
the appropriate system documentation for your system).

My suspicion given your description of this as a large file would
be that you're getting EOVERFLOW -- the file can not be opened because
an off_t (file offset value) in your program's environment is too
small to describe the entire file space.

I don't know if there's a standard solution to this issue (a little
googling seems to imply that there's a standard approach but the
details are implementation specific), so I'd check your
documentation on large file support for whichever systems you choose
to support and act accordingly. (I suspect this will be a compile-time
flag or argument to switch you over to 64-bit file operations).

Don

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char **argv)
{
FILE *f;
char fn[2000];

strcpy(fn,"/some_place/somefile.bin");

if ((f = fopen(fn, "rb")) == NULL) {
fprintf(stderr, "%s: couldn't open file %s for read\n", argv
[0], fn);
exit(1)
}

fclose(f);

return (0);
}

The only thing I could think of was that perhaps it was because the
file wasn't in my data area, but I checked the permissions and they
seemed ok? And I copied the file local to my directory and that didn't
change things.

ls -l /some_file/someplace.bin
-rw-r----- 1 someone global 3238400000 Jun 4 19:13 /some_file/
someplace.bin

Many thanks,

Martin

 

[Mark Storkamp]

Hi,

I am trying to write a quick program to access data from a large file
(3238400000), so I intended to use fseek to move around it. However I
can't even open a file pointer and for the life of me I can't spot the
problem. I end up with NULL being returned by fopen! Any thoughts
would be appreciated.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char **argv)
{
FILE *f;
char fn[2000];

strcpy(fn,"/some_place/somefile.bin");

if ((f = fopen(fn, "rb")) == NULL) {
fprintf(stderr, "%s: couldn't open file %s for read\n", argv
[0], fn);
exit(1)
}

fclose(f);

return (0);
}

The only thing I could think of was that perhaps it was because the
file wasn't in my data area, but I checked the permissions and they
seemed ok? And I copied the file local to my directory and that didn't
change things.

ls -l /some_file/someplace.bin
-rw-r----- 1 someone global 3238400000 Jun 4 19:13 /some_file/
someplace.bin

Your file is named /some_file/someplace.bin, and you're trying to open
/some_place/somefile.bin

 

[Keith Thompson]

I am trying to write a quick program to access data from a large file
(3238400000), so I intended to use fseek to move around it. However I
can't even open a file pointer and for the life of me I can't spot the
problem. I end up with NULL being returned by fopen! Any thoughts
would be appreciated.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char **argv)
{
FILE *f;
char fn[2000];

strcpy(fn,"/some_place/somefile.bin");

At least for this small program, you don't need to copy the string to
an array; you can just pass the literal directly to fopen().

if ((f = fopen(fn, "rb")) == NULL) {
fprintf(stderr, "%s: couldn't open file %s for read\n", argv
[0], fn);
exit(1)
}

fclose(f);

return (0);
}

I presume you're getting the "couldn't open file" message, though you
didn't actually say so.

fopen() typically sets errno to indicate why it failed, though the C
standard doesn't actually require it to do so. Try adding
#include <errno.h>
to the top of your program,
errno = 0;
just before the fopen call, and add a call to perror() if the
fopen fails.

The only thing I could think of was that perhaps it was because the
file wasn't in my data area, but I checked the permissions and they
seemed ok? And I copied the file local to my directory and that didn't
change things.

ls -l /some_file/someplace.bin
-rw-r----- 1 someone global 3238400000 Jun 4 19:13 /some_file/
someplace.bin

I can't tell from the "ls -l" output whether you have permission to
read the file, but if you were able to copy it then you should be
able to read it (unless you were doing something <OT>like sudo</OT>
to mess with your access privileges).

I note that "/some_place/somefile.bin" and "/some_file/someplace.bin"
are not the same. It looks like you've re-typed at least some of
what you're showing us rather than copy-and-pasting it. There could
easily be some transcription errors that are hiding whatever your
real problem is.

 

[Mart.]

Hi,

I am trying to write a quick program to access data from a large file
(3238400000), so I intended to use fseek to move around it. However I
can't even open a file pointer and for the life of me I can't spot the
problem. I end up with NULL being returned by fopen! Any thoughts
would be appreciated.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char **argv)
{
    FILE *f;
    char  fn[2000];

    strcpy(fn,"/some_place/somefile.bin");

    if ((f = fopen(fn, "rb")) == NULL) {
        fprintf(stderr, "%s: couldn't open file %s for read\n", argv
[0], fn);
        exit(1)
    }

    fclose(f);

    return (0);
}

The only thing I could think of was that perhaps it was because the
file wasn't in my data area, but I checked the permissions and they
seemed ok? And I copied the file local to my directory and that didn't
change things.

ls -l /some_file/someplace.bin
-rw-r----- 1 someone global 3238400000 Jun  4 19:13 /some_file/
someplace.bin

Your file is named /some_file/someplace.bin, and you're trying to open
/some_place/somefile.bin

sorry that was me just quickly substituting a path. That isn't a real
file or path

 

[Mart.]

I am trying to write a quick program to access data from a large file
(3238400000), so I intended to use fseek to move around it. However I
can't even open a file pointer and for the life of me I can't spot the
problem. I end up with NULL being returned by fopen! Any thoughts
would be appreciated.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char **argv)
{
    FILE *f;
    char  fn[2000];

    strcpy(fn,"/some_place/somefile.bin");

At least for this small program, you don't need to copy the string to
an array; you can just pass the literal directly to fopen().

    if ((f = fopen(fn, "rb")) == NULL) {
        fprintf(stderr, "%s: couldn't open file %s for read\n", argv
[0], fn);
        exit(1)
    }

    fclose(f);

    return (0);
}

I presume you're getting the "couldn't open file" message, though you
didn't actually say so.

fopen() typically sets errno to indicate why it failed, though the C
standard doesn't actually require it to do so.  Try adding
    #include <errno.h>
to the top of your program,
    errno = 0;
just before the fopen call, and add a call to perror() if the
fopen fails.

The only thing I could think of was that perhaps it was because the
file wasn't in my data area, but I checked the permissions and they
seemed ok? And I copied the file local to my directory and that didn't
change things.

ls -l /some_file/someplace.bin
-rw-r----- 1 someone global 3238400000 Jun  4 19:13 /some_file/
someplace.bin

I can't tell from the "ls -l" output whether you have permission to
read the file, but if you were able to copy it then you should be
able to read it (unless you were doing something <OT>like sudo</OT>
to mess with your access privileges).

I note that "/some_place/somefile.bin" and "/some_file/someplace.bin"
are not the same.  It looks like you've re-typed at least some of
what you're showing us rather than copy-and-pasting it.  There could
easily be some transcription errors that are hiding whatever your
real problem is.

--
Keith Thompson (The_Other_Keith) (e-mail address removed)  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Sorry as I mentioned I just added the some place thing as a quick
substitute for the full path. The rest is copied and pasted.

I haven't used perror before, so i hope I did it right.

it returned...

Value too large for defined data type

 

[Mart.]

I am trying to write a quick program to access data from a large file
(3238400000), so I intended to use fseek to move around it. However I
can't even open a file pointer and for the life of me I can't spot the
problem. I end up with NULL being returned by fopen! Any thoughts
would be appreciated.
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main(int argc, char **argv)
{
    FILE *f;
    char  fn[2000];
    strcpy(fn,"/some_place/somefile.bin");

At least for this small program, you don't need to copy the string to
an array; you can just pass the literal directly to fopen().

    if ((f = fopen(fn, "rb")) == NULL) {
        fprintf(stderr, "%s: couldn't open file %s for read\n", argv
[0], fn);
        exit(1)
    }
    fclose(f);
    return (0);
}

I presume you're getting the "couldn't open file" message, though you
didn't actually say so.

fopen() typically sets errno to indicate why it failed, though the C
standard doesn't actually require it to do so.  Try adding
    #include <errno.h>
to the top of your program,
    errno = 0;
just before the fopen call, and add a call to perror() if the
fopen fails.

I can't tell from the "ls -l" output whether you have permission to
read the file, but if you were able to copy it then you should be
able to read it (unless you were doing something <OT>like sudo</OT>
to mess with your access privileges).

I note that "/some_place/somefile.bin" and "/some_file/someplace.bin"
are not the same.  It looks like you've re-typed at least some of
what you're showing us rather than copy-and-pasting it.  There could
easily be some transcription errors that are hiding whatever your
real problem is.

--
Keith Thompson (The_Other_Keith) (e-mail address removed)  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Sorry as I mentioned I just added the some place thing as a quick
substitute for the full path. The rest is copied and pasted.

I haven't used perror before, so i hope I did it right.

it returned...

Value too large for defined data type

I added #define _FILE_OFFSET_BITS 64 and that seems to have cured the
problem, but i will need to check this more thoroughly in the morning.

 

[Keith Thompson]

I added #define _FILE_OFFSET_BITS 64 and that seems to have cured the
problem, but i will need to check this more thoroughly in the morning.

Check your system's documentation for the fopen() function.

On my system, it explains the circumstances in which it can fail and
the value stored in errno in each case. <OT>It refers to the open()
function, which can fail as you described.</OT>

Note again that the C standard doesn't even require fopen() to set
errno on failure. I think your system's documentation should answer
any questions you have, but if not, I suggest posting to
comp.unix.programmer.

 

[Mart.]

[...]
Sorry as I mentioned I just added the some place thing as a quick
substitute for the full path. The rest is copied and pasted.

     Including the syntax error?

     My patience with people who ask for help with code and then show
some other piece of code altogether is limited.  I don't choose to
try to help until and unless an accurate problem report arrives.

     Still waiting ...

I think you are exaggerating slightly aren't you? Whilst I appreciate
the mistake, it was an honest mistake to make the example as self
contained as possible. I didn't assassinate the king.

The piece of code as I have already stated is a direct copy and as I
also stated all I did was alter the path in the posting.

The help from the other posters has assisted *I think* with the
problem. From what I understand as the file size exceeds 2^31 it runs
into trouble on my solaris box.

Thanks

Martin

 

[Keith Thompson]

[...]
Sorry as I mentioned I just added the some place thing as a quick
substitute for the full path. The rest is copied and pasted.

     Including the syntax error?

     My patience with people who ask for help with code and then show
some other piece of code altogether is limited.  I don't choose to
try to help until and unless an accurate problem report arrives.

     Still waiting ...

I think you are exaggerating slightly aren't you? Whilst I appreciate
the mistake, it was an honest mistake to make the example as self
contained as possible. I didn't assassinate the king.

The piece of code as I have already stated is a direct copy and as I
also stated all I did was alter the path in the posting.

No, that's not all you did. The code you posted contained the
following lines:

exit(1)
}

Note the lack of a semicolon on the call to exit.

When posting code here, it's more important than you realize
to copy-and-paste the *exact* code that you actually fed to the
compiler. A missing semicolon may not seem like a big deal, but it
suggests that you've re-typed or paraphrased the code rather than
showing us your actual code, and we can't possibly guess how else
the code you posted might differ from your real code.

Perhaps the missing semicolon and the path name were the only
differences, but how are we supposed to know that, when you yourself
were only aware of one of them?

I'm not trying to pick on you here, though I understand it probably
seems that way. We get all sorts of people posting here, including
some who post some manually re-typed C-like gibberish and ask us why
they get some unspecified error on line 17.

If you copy-and-paste the exact code you feed to the compiler, it's
easier to get it right than to get it wrong.

The help from the other posters has assisted *I think* with the
problem. From what I understand as the file size exceeds 2^31 it runs
into trouble on my solaris box.

Yes, I think that was the problem.

 

[Mart.]

Mart. wrote:
[...]
Sorry as I mentioned I just added the some place thing as a quick
substitute for the full path. The rest is copied and pasted.
     Including the syntax error?
     My patience with people who ask for help with code and then show
some other piece of code altogether is limited.  I don't choose to
try to help until and unless an accurate problem report arrives.
     Still waiting ...

I think you are exaggerating slightly aren't you? Whilst I appreciate
the mistake, it was an honest mistake to make the example as self
contained as possible. I didn't assassinate the king.

The piece of code as I have already stated is a direct copy and as I
also stated all I did was alter the path in the posting.

No, that's not all you did.  The code you posted contained the
following lines:

        exit(1)
    }

Note the lack of a semicolon on the call to exit.

When posting code here, it's more important than you realize
to copy-and-paste the *exact* code that you actually fed to the
compiler.  A missing semicolon may not seem like a big deal, but it
suggests that you've re-typed or paraphrased the code rather than
showing us your actual code, and we can't possibly guess how else
the code you posted might differ from your real code.

Perhaps the missing semicolon and the path name were the only
differences, but how are we supposed to know that, when you yourself
were only aware of one of them?

I'm not trying to pick on you here, though I understand it probably
seems that way.  We get all sorts of people posting here, including
some who post some manually re-typed C-like gibberish and ask us why
they get some unspecified error on line 17.

If you copy-and-paste the exact code you feed to the compiler, it's
easier to get it right than to get it wrong.

The help from the other posters has assisted *I think* with the
problem. From what I understand as the file size exceeds 2^31 it runs
into trouble on my solaris box.

Yes, I think that was the problem.

--
Keith Thompson (The_Other_Keith) (e-mail address removed)  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

I can only restate what I already stated. It was a direct copy and
paste, I then adjusted the path as I thought there wasn't any point in
having an elongated path that didn't really add to the problem. Now
that I look at the example I also see the missing semi colon. So
perhaps I knocked it off by accident. I accept (and don't dispute) the
argument put regarding the copy and paste. My gripe was the tone. Of
course I appreciate the help, sometimes it is also difficult to create
a self contained example that succinctly explains the problem. I'll
get there one day!

Thanks again,

Martin

 

[Paul N]

The piece of code as I have already stated is a direct copy and as I
also stated all I did was alter the path in the posting.

It's perhaps worth pointing out that one common problem in C is

fp = fopen("\path\file.ext", "rb");

where the problem is the backspaces which mangle the following
characters. If the poster changes this to

fp = fopen("file.ext", "rb");

before posting people may never find the problem. This is similar
(though not quite the same, I accept) to what you did. So in this case
you were very close to setting an unsolvable problem.

 

[Keith Thompson]

Paul N wrote: [...]

fp = fopen("\path\file.ext", "rb");

where the problem is the backspaces which mangle the following
characters.

I assume you mean "backslashes"? [...]
Or, simply use "real" slashes:

fp = fopen("/path/file.txt", "rb");

How do you now that's equivalent? (How do you know we're talking
about MS Windows?)