File exist

[paytam]

Hi all
Can anyone tell me how can I check that a file exist or no.I mean when
you use this commands
FILE *fp;
if(!fp)
//Could not open the file
doen't show why it can not open it,may be the file doesn't exist.Now
tell me what should I do!
Thanks

[Vladimir S. Oka]

pa****@gmail.com opined:

Hi all
Can anyone tell me how can I check that a file exist or no.I mean
when you use this commands
FILE *fp;
if(!fp)
//Could not open the file
doen't show why it can not open it,may be the file doesn't exist.Now
tell me what should I do!
You can try reading `errno` (from <errno.h>) do get to the error code,
provided your implementation gives you one, and it's sensible (it's
not required by the Standard to do that). You'd have to set `errno` to
0 before calling `fopen()`, as library functions never do that. You
should consult documentation that came with your C compiler to see
what `errno` codes are available, and whether they can help you.

If your implementation does set useful error codes, you can then use
`strerror()` from <string.h> to get a huan-readable error string, or
`perror()` from <stdio.h>. Look them up in your manual.

Again, if your implementation does not provide sensible error
codes/messages, you're out in the cold. OTH, relying on your
implementation error codes/messages is more likely than not to make
your code non-portable.

--Ever heard of .cshrc?

That's a city in Bosnia. Right?
(Discussion in comp.os.linux.misc on the intuitiveness of commands.)

<http://clc-wiki.net/wiki/Introduction_to_comp.lang.c>

[MH]

I think this is what you are looking for :

FILE *fp

main(){

fp=fopen("something.txt","r"); // open for reading
if (!fp) printf ("file doesn't exist");
else prinf("file exist");
fclose(fp);
}

[Bill Pursell]

MH wrote:

I think this is what you are looking for :

FILE *fp

main(){

fp=fopen("something.txt","r"); // open for reading
if (!fp) printf ("file doesn't exist");
else prinf("file exist");
fclose(fp);
}

Consider the following:
% touch something.txt
% chmod -r something.txt
% a.out
file doesn't exist

That's not correct.

[Ico]

MH <mi******@o2.pl> wrote:

I think this is what you are looking for :

FILE *fp

main(){

fp=fopen("something.txt","r"); // open for reading
if (!fp) printf ("file doesn't exist");
else prinf("file exist");
fclose(fp);
}

Sorry to be nitpicking, but this code has some serious flaws: You didn't
include stdio.h, which you need for fopen, fclose and printf. main()
should return an int. Your printf's might not show any output because
you forgot the terminating newlines, and the fclose() causes serious
undefined behaviour when the fopen() fails.

#include <stdio.h>

int main(void)
{
FILE *fp;

fp = fopen("something.txt", "r");

if(fp == NULL) {
printf("file doesn't exist\n");
} else {
printf("file exists\n");
fclose(fp);
}

return 0;
}
--
:wq
^X^Cy^K^X^C^C^C^C

[osmium]

"Ico" writes:

I think this is what you are looking for :

FILE *fp

main(){

fp=fopen("something.txt","r"); // open for reading
if (!fp) printf ("file doesn't exist");
else prinf("file exist");
fclose(fp);
}

Sorry to be nitpicking, but this code has some serious flaws:

Not to mention that it has nothing whatsoever to do with the question asked.

[Richard G. Riley]

On 2006-04-16, pa****@gmail.com <pa****@gmail.com> wrote:

Hi all
Can anyone tell me how can I check that a file exist or no.I mean when
you use this commands
FILE *fp;
if(!fp)
//Could not open the file
doen't show why it can not open it,may be the file doesn't exist.Now
tell me what should I do!
Thanks

I'm guessing from your pseudo code you already know how to open a file
and set fp etc.

On my system the man page for fopen refers me to "open" which lists
the values that the global "errno" is set to in the event of a failed
file open operation.

According to one man page I checked, fopen was ansi-c compliant. I cant
confirm this one way or another.
good luck

[paytam]

AT first thanks beacause of your informations,but I knew these,that you
wrote here.I think I don't explain my question well!
This is my question
What is the correct means of fp=='\0'
(I mean if fp=='\0' is equal to "FILE DOES NOT EXIST" or "you have some
errors <I don't know what but imagine something like you don't have
right permission to open the file>")
thanks

[Ico]

pa****@gmail.com wrote:

AT first thanks beacause of your informations,but I knew these,that you
wrote here.I think I don't explain my question well!
This is my question
What is the correct means of fp=='\0'
(I mean if fp=='\0' is equal to "FILE DOES NOT EXIST" or "you have some
errors <I don't know what but imagine something like you don't have
right permission to open the file>")
thanks

I believe Vladimir answered this part of your question well : fopen()
returns NULL on error (and NULL is not the same as '\0' !), and you can
inspect errno to find the nature of the error.

--
:wq
^X^Cy^K^X^C^C^C^C

[paytam]

AT first thanks beacause of your informations,but I knew these,that you
wrote here.I think I don't explain my question well!
This is my question
What is the correct means of fp=='\0'
(I mean if fp=='\0' is equal to "FILE DOES NOT EXIST" or "you have some
errors <I don't know what but imagine something like you don't have
right permission to open the file>")
thanks

[Nick Keighley]

please leave some context in your post (quote what you are replying
to (as I do))

pa****@gmail.com wrote:

AT first thanks beacause of your informations,but I knew these,that you
wrote here.I think I don't explain my question well!
This is my question
What is the correct means of fp=='\0'
you shouldn't test against a null character ('\0') as fp is a pointer.
To be clear you should test against 0 or NULL (my preference)

If fopen() returns a null pointer it means it has failed.
(I mean if fp=='\0' is equal to "FILE DOES NOT EXIST" or "you have some
errors <I don't know what but imagine something like you don't have
right permission to open the file>")

there are many reasons fopen() can fail including the file's
non-existance
and file permission problems. Standard C does not distinguish these
reasons but as others have pointed out many implementations (including
Unix) set errno so you could then use strerr() or perror() to find out
why it
failed.
--
Nick Keighley

[Joe Wright]

pa****@gmail.com wrote:

Hi all
Can anyone tell me how can I check that a file exist or no.I mean when
you use this commands
FILE *fp;
if(!fp)
//Could not open the file
doen't show why it can not open it,may be the file doesn't exist.Now
tell me what should I do!
Thanks

Consider this..

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

int main(int argc, char *argv[]) {
FILE *fp = NULL;
char *file = NULL;
errno = 0;
if (argc > 1) {
file = argv[1];
if ((fp = fopen(file, "r+")) == NULL)
perror(file), exit(EXIT_FAILURE);
printf("%s is open\n", file);
fclose(fp);
}
return 0;
}

The Standard makes no guarantees about errno as far as I know but most
implementations will handle it this way. A failing function will set
errno with an integer indicating the type of error (see errno.h). Then
'perror(char *);' will print your message, a colon and a description of
the error.

I open the file with "r+" so that I'll get an access error if the file
is read-only.
--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Ico]

osmium <r1********@comcast.net> wrote:

"Ico" writes:

I think this is what you are looking for :

FILE *fp

main(){

fp=fopen("something.txt","r"); // open for reading
if (!fp) printf ("file doesn't exist");
else prinf("file exist");
fclose(fp);
}

Sorry to be nitpicking, but this code has some serious flaws:

Not to mention that it has nothing whatsoever to do with the question asked.

I do not agree with that. the O.P. is clearly a beginner at C language,
and code that cause this kind of severe undefined behaviour (especially
fclose()'ing a NULL file descriptor) deserves some attention and should
be corrected. In my humble opinion, causing a segmentation fault,
bluescreen, or whatever symptoms his system may show, is not giving the
O.P. a good feeling about his first C programs.

--
:wq
^X^Cy^K^X^C^C^C^C

[ed]

On 16 Apr 2006 01:53:03 -0700
pa****@gmail.com wrote:

Hi all
Can anyone tell me how can I check that a file exist or no.I mean when
you use this commands
FILE *fp;
if(!fp)
//Could not open the file
doen't show why it can not open it,may be the file doesn't exist.Now
tell me what should I do!

Try using stat(5).

NAME
stat, fstat, lstat - get file status

SYNOPSIS
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>

int stat(const char *file_name, struct stat *buf);
int fstat(int filedes, struct stat *buf);
int lstat(const char *file_name, struct stat *buf);

DESCRIPTION
These functions return information about the specified file.
You do not need any access rights to the file to get this
information but you need search rights to all directories named
in the path leading to the file.

stat stats the file pointed to by file_name and fills in buf.

See the full man page for further details if you think it might be of
use.

--
Regards, Ed :: http://www.s5h.net
:%s/\t/ /g :: proud unix system person
:%s/Open Source/Free Software/g

[osmium]

"Ico" writes:

osmium <r1********@comcast.net> wrote:

"Ico" writes:

I think this is what you are looking for :

FILE *fp

main(){

fp=fopen("something.txt","r"); // open for reading
if (!fp) printf ("file doesn't exist");
else prinf("file exist");
fclose(fp);
}

Sorry to be nitpicking, but this code has some serious flaws:

Not to mention that it has nothing whatsoever to do with the question
asked.

I do not agree with that. the O.P. is clearly a beginner at C language,
and code that cause this kind of severe undefined behaviour (especially
fclose()'ing a NULL file descriptor) deserves some attention and should
be corrected. In my humble opinion, causing a segmentation fault,
bluescreen, or whatever symptoms his system may show, is not giving the
O.P. a good feeling about his first C programs.

The OP didn't have any fclose. The *response* had the fclose you don't like.
The OP asked *why* wouldn't the file open? The code posted allegedly told
him how to open a file - something he already knew.

So he got a bad answer to a question he didn't ask. I don't really consider
that helpful to the OP.

[Skarmander]

pa****@gmail.com wrote:

Hi all
Can anyone tell me how can I check that a file exist or no.I mean when
you use this commands
FILE *fp;
if(!fp)
//Could not open the file
doen't show why it can not open it,may be the file doesn't exist.Now
tell me what should I do!
Thanks

In addition to all other answers you got, please read the FAQ: http://c-faq.com.

I recommend reading it all, but your question in particular is question 19.11.

S.

[Ico]

osmium <r1********@comcast.net> wrote:

"Ico" writes:

osmium <r1********@comcast.net> wrote:

"Ico" writes:

Sorry to be nitpicking, but this code has some serious flaws:

Not to mention that it has nothing whatsoever to do with the question
asked.

I do not agree with that. the O.P. is clearly a beginner at C language,
and code that cause this kind of severe undefined behaviour (especially
fclose()'ing a NULL file descriptor) deserves some attention and should
be corrected. In my humble opinion, causing a segmentation fault,
bluescreen, or whatever symptoms his system may show, is not giving the
O.P. a good feeling about his first C programs.

The OP didn't have any fclose. The *response* had the fclose you don't like.
The OP asked *why* wouldn't the file open? The code posted allegedly told
him how to open a file - something he already knew.

So he got a bad answer to a question he didn't ask. I don't really consider
that helpful to the OP.

I *do* consider it helpful to comment on broken code - wether posted by
the OP or not - so we seem to disagree on this point. I don't think
there is much we can do about that, I'm sorry.
--
:wq
^X^Cy^K^X^C^C^C^C

[Default User]

pa****@gmail.com wrote:

AT first thanks beacause of your informations,but I knew these,that
you wrote here.I think I don't explain my question well!
This is my question

Please read the information below.

Brian

--
Please quote enough of the previous message for context. To do so from
Google, click "show options" and use the Reply shown in the expanded
header.

[Keith Thompson]

ed <[e-mail]> writes:

On 16 Apr 2006 01:53:03 -0700
pa****@gmail.com wrote:

Can anyone tell me how can I check that a file exist or no.

[...] Try using stat(5).

There is no stat() function in standard C. Using it will limit the
portability of your code. See comp.unix.programmer.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Rod Pemberton]

"osmium" <r1********@comcast.net> wrote in message
news:4a************@individual.net...

"Ico" writes:

osmium <r1********@comcast.net> wrote:

"Ico" writes:

> I think this is what you are looking for :
>
> FILE *fp
>
> main(){
>
> fp=fopen("something.txt","r"); // open for reading
> if (!fp) printf ("file doesn't exist");
> else prinf("file exist");
> fclose(fp);
> }

Sorry to be nitpicking, but this code has some serious flaws:

Not to mention that it has nothing whatsoever to do with the question
asked.
I do not agree with that. the O.P. is clearly a beginner at C language,
and code that cause this kind of severe undefined behaviour (especially
fclose()'ing a NULL file descriptor) deserves some attention and should
be corrected. In my humble opinion, causing a segmentation fault,
bluescreen, or whatever symptoms his system may show, is not giving the
O.P. a good feeling about his first C programs.

The OP didn't have any fclose. The *response* had the fclose you don't

like. The OP asked *why* wouldn't the file open? The code posted allegedly told
him how to open a file - something he already knew.
"...allegedly told him..." - since when does code talk? If you want
inanimate or personified talking objects, read the Bible, smoke dope, etc...

"...something he already knew..." - apparently not. The OP's post didn't
contain anything which would indicate that.
So he got a bad answer to a question he didn't ask. I don't really consider that helpful to the OP.

I proffer that you made some poor assumptions which resulted in faulty
circular logic...
RP

[Claude Yih]

Keith Thompson wrote:

ed <[e-mail]> writes:

On 16 Apr 2006 01:53:03 -0700
pa****@gmail.com wrote:

Can anyone tell me how can I check that a file exist or no.

[...]

Try using stat(5).

There is no stat() function in standard C. Using it will limit the
portability of your code. See comp.unix.programmer.

I learnt from others that there is a function named access can be used
to detect if a dedicated file exists. The function is as follows:

int access (char* filename, int mode)

For instance, if I wanted to know whether /opt/test.log exists, I would
call this function as
int flag = access("/opt/test.log", 0);

However, this function is included in <io.h>, perhaps it's not a
standard function either.

[Flash Gordon]

Claude Yih wrote:

Keith Thompson wrote:

ed <[e-mail]> writes:

On 16 Apr 2006 01:53:03 -0700
pa****@gmail.com wrote:
Can anyone tell me how can I check that a file exist or no.

[...]

Try using stat(5).

There is no stat() function in standard C. Using it will limit the
portability of your code. See comp.unix.programmer.

I learnt from others that there is a function named access can be used
to detect if a dedicated file exists. The function is as follows:

int access (char* filename, int mode)

For instance, if I wanted to know whether /opt/test.log exists, I would
call this function as
int flag = access("/opt/test.log", 0);

However, this function is included in <io.h>, perhaps it's not a
standard function either.

It is not part of standard C. As I'm sure others have said in this
thread standard C does not provide any portable method to see if a file
exists. So you can be sure that any method you find goes beyond what
standard C provides.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php

[Mr John FO Evans]

In article <76************@news.flash-gordon.me.uk>, Flash Gordon
<sp**@flash-gordon.me.uk> wrote:

Claude Yih wrote:

Keith Thompson wrote:

ed <[e-mail]> writes:
On 16 Apr 2006 01:53:03 -0700
pa****@gmail.com wrote:
> Can anyone tell me how can I check that a file exist or no.
[...]
Try using stat(5).
There is no stat() function in standard C. Using it will limit the
portability of your code. See comp.unix.programmer.

I learnt from others that there is a function named access can be used
to detect if a dedicated file exists. The function is as follows:

int access (char* filename, int mode)

For instance, if I wanted to know whether /opt/test.log exists, I would
call this function as
int flag = access("/opt/test.log", 0);

However, this function is included in <io.h>, perhaps it's not a
standard function either.

It is not part of standard C. As I'm sure others have said in this
thread standard C does not provide any portable method to see if a file
exists. So you can be sure that any method you find goes beyond what
standard C provides.

What is wrong with attempting to open the file and if there is no error
closing it again? Surely this is standard 'C'?

John
--
_ _________________________________________
/ \._._ |_ _ _ /' Orpheus Internet Services
\_/| |_)| |(/_|_|_> / 'Internet for Everyone'
_______ | ___________./ http://www.orpheusinternet.co.uk

[Kenneth Brody]

Mr John FO Evans wrote:
[...]

>> On 16 Apr 2006 01:53:03 -0700
>> pa****@gmail.com wrote:
>>> Can anyone tell me how can I check that a file exist or no.

[...] What is wrong with attempting to open the file and if there is no error
closing it again? Surely this is standard 'C'?

Because if it fails, it won't (necessarily) tell you why. As has been
pointed out elsethread, insufficient access privileges will fail the
same way as a non-existent file. While many implementations will set
errno to the reason for the failure, such behavior is not guaranteed by
the Standard.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Keith Thompson]

Mr John FO Evans <mi***@orpheusmail.co.uk> writes:

In article <76************@news.flash-gordon.me.uk>, Flash Gordon
<sp**@flash-gordon.me.uk> wrote:

[...]

It is not part of standard C. As I'm sure others have said in this
thread standard C does not provide any portable method to see if a file
exists. So you can be sure that any method you find goes beyond what
standard C provides.

What is wrong with attempting to open the file and if there is no error
closing it again? Surely this is standard 'C'?

Yes, but it only tells you whether you were able to open the file; it
doesn't necessarily tell you why. (And fopen() doesn't even
necessarily set errno to a meaningful value.)

On some systems, it might be possible to open a file in binary mode
but not in text mode, or vice versa.

In some cases, it's not even possible to determine whether a file
exists; you might not have permission to ask (e.g., if the file is in
a directory you don't have permission to read). Also, a file might
exist when you test it, but cease to exist before you use it.

Usually the best approach is to try to open the file, and handle the
error if the attempt fails. Providing information about *why* it
failed can be useful, but it isn't absolutely necessary, and it can't
be done portably.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Flash Gordon]

Mr John FO Evans wrote:

In article <76************@news.flash-gordon.me.uk>, Flash Gordon
<sp**@flash-gordon.me.uk> wrote:

Claude Yih wrote:

Keith Thompson wrote:

ed <[e-mail]> writes:
> On 16 Apr 2006 01:53:03 -0700
> pa****@gmail.com wrote:
>> Can anyone tell me how can I check that a file exist or no.
[...]
> Try using stat(5).
There is no stat() function in standard C. Using it will limit the
portability of your code. See comp.unix.programmer.
I learnt from others that there is a function named access can be used
to detect if a dedicated file exists. The function is as follows:

int access (char* filename, int mode)

For instance, if I wanted to know whether /opt/test.log exists, I would
call this function as
int flag = access("/opt/test.log", 0);

However, this function is included in <io.h>, perhaps it's not a
standard function either.

It is not part of standard C. As I'm sure others have said in this
thread standard C does not provide any portable method to see if a file
exists. So you can be sure that any method you find goes beyond what
standard C provides.

What is wrong with attempting to open the file and if there is no error
closing it again? Surely this is standard 'C'?

It's standard C but it does not prove the file does not exist. It might
exist but your have permission set preventing you from opening it
(perhaps a different user owns it) or another process might have it
opened exclusively, or...
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

[Kenneth Brody]

Keith Thompson wrote:
[...]

Usually the best approach is to try to open the file, and handle the
error if the attempt fails. Providing information about *why* it
failed can be useful, but it isn't absolutely necessary, and it can't
be done portably.

Isn't this portable?

... proper #include's, etc. implied ...

errno=0;
f = fopen(filename,mode);
if ( f == NULL )
{
if ( errno != 0 )
perror(filename);
else
fprintf(stderr,"fopen() of %s failed.\n",filename);
exit(EXIT_FAILURE);
}
--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Keith Thompson]

Kenneth Brody <ke******@spamcop.net> writes:

Keith Thompson wrote:
[...]

Usually the best approach is to try to open the file, and handle the
error if the attempt fails. Providing information about *why* it
failed can be useful, but it isn't absolutely necessary, and it can't
be done portably.

Isn't this portable?

... proper #include's, etc. implied ...

errno=0;
f = fopen(filename,mode);
if ( f == NULL )
{
if ( errno != 0 )
perror(filename);
else
fprintf(stderr,"fopen() of %s failed.\n",filename);
exit(EXIT_FAILURE);
}

No, since the standard doesn't say that fopen() sets errno on failure.
perror() could print something silly like "foo.txt: No error", or
"foo.txt: File exists".

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Flash Gordon]

Kenneth Brody wrote:

Keith Thompson wrote:
[...]

Usually the best approach is to try to open the file, and handle the
error if the attempt fails. Providing information about *why* it
failed can be useful, but it isn't absolutely necessary, and it can't
be done portably.

Isn't this portable?

... proper #include's, etc. implied ...

errno=0;
f = fopen(filename,mode);
if ( f == NULL )
{
if ( errno != 0 )
perror(filename);
else
fprintf(stderr,"fopen() of %s failed.\n",filename);
exit(EXIT_FAILURE);
}

It's portable, but it might always print out "fopen() of %s failed.\n"
and never give a reason on some implementations.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

[Mr John FO Evans]

After reading all the comments on this thread I am astounded that the 'C'
standard does not require that fopen returns a meaningful error when it
fails. Surly this is an ommision - or perhaps it is a acceptance that
computer systems suppliers do not like standards and hence do not provide
meaningful error returns from their lower level routines?

John
--
_ _________________________________________
/ \._._ |_ _ _ /' Orpheus Internet Services
\_/| |_)| |(/_|_|_> / 'Internet for Everyone'
_______ | ___________./ http://www.orpheusinternet.co.uk

[Richard Bos]

Mr John FO Evans <mi***@orpheusmail.co.uk> wrote:

After reading all the comments on this thread I am astounded that the 'C'
standard does not require that fopen returns a meaningful error when it
fails.
fopen() is required to return a null pointer when it fails. This means
"the file could not be opened". To require more information (e.g., in
errno) would be tricky. For example, how do you describe what level of
"meaningful" you demand without making assumptions about how the
underlying IO system works - assumptions that _will_ be inaccurate
sooner or later?
Surly this is an ommision - or perhaps it is a acceptance that
computer systems suppliers do not like standards and hence do not provide
meaningful error returns from their lower level routines?

It is at least an acknowledgement of the fact that _if_ you run across
such a crummy OS, you can't blame the implementation for not having more
information to give the user in the first place.

Richard

[Keith Thompson]

Mr John FO Evans <mi***@orpheusmail.co.uk> writes:

After reading all the comments on this thread I am astounded that the 'C'
standard does not require that fopen returns a meaningful error when it
fails. Surly this is an ommision - or perhaps it is a acceptance that
computer systems suppliers do not like standards and hence do not provide
meaningful error returns from their lower level routines?

Not at all. The C standard merely doesn't require *all*
implementations to report why fopen() failed. This allows C to be
implemented on a wide variety of systems, some of which may not always
provide meaningful information about errors.

The only errno values required by the C standard are EDOM, EILSEQ, and
ERANGE. (The corresponding error messages on one system are "Argument
out of domain", "Illegal byte sequence", and "Result too large",
respectively.)

But implementations are free to set errno on a failed fopen(), and to
provide more error codes than the minimal set required by the standard
-- and in fact most implementations do so.

Something like this:

errno = 0;
if ((f = fopen(filename, "r")) == NULL) {
perror(filename);
}

is very likely to give a meaningful error message on most systems --
and in fact is guaranteed to do so on many systems. If your
implementation doesn't give you a meaningful error message, you can
still complain to your vendor; you just can't argue that the
implementation doesn't conform to the C sftandard.

Having said that, I will acknowledge one weakness. There's no way for
a program to tell whether the implementation sets errno to a
meaningful value. You can generally tell by reading the
implementation's documentation, but that's not very helpful if you're
trying to write portable code.

If fopen() fails and errno is non-zero, it's possible that it was set
by some function called by fopen() for reasons having nothing to do
with fopen's failure. For example, fopen() might call malloc(),
malloc() could fail and set errno, then fopen() could fall back to
some alternative mechanism that doesn't use dynamically-allocated
memory, and then fail because the file doesn't exist. (That
particular scenario isn't very plausible, but something along those
lines could happen.)

It might have been more convenient if each library function defined in
the standard were required on failure to either (a) set errno to a
meaningful value, or (b) reset it to the value it had before the call.
If that were the case, then this:

errno = 0;
if ((f = fopen(filename, "r")) == NULL) {
if (errno == 0) {
fprintf(stderr, "fopen failed for %s\n", filename);
}
else {
perror(filename);
}
}

could always be depended on to produce a meaningful error message.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Laurent Deniau]

Mr John FO Evans wrote:

After reading all the comments on this thread I am astounded that the 'C'
standard does not require that fopen returns a meaningful error when it
fails. Surly this is an ommision

I don't think so and I partially disagree with some answer in this
thread. Strictly speaking, a failure reported by fopen in "r+" mode
means that the file cannot be read nor write which is the same as "does
not exist" from the point of view of C, whatever the reason is. If you
want a more subtle diagnostic which matches better the user's
expectation, then you have to rely on the filesystem API (e.g. stat).
One cannot state that stat() is not standard on one hand and expect an
information about something that C ignores (e.g. access rights) on the
other hand.

my .02 euro.

a+, ld.

[Flash Gordon]

Laurent Deniau wrote:

Mr John FO Evans wrote:

After reading all the comments on this thread I am astounded that the
'C' standard does not require that fopen returns a meaningful error
when it
fails. Surly this is an ommision
I don't think so and I partially disagree with some answer in this
thread. Strictly speaking, a failure reported by fopen in "r+" mode
means that the file cannot be read nor write which is the same as "does
not exist" from the point of view of C, whatever the reason is.

I disagree, does not exist and cannot be opened are very different concepts.
If you
want a more subtle diagnostic which matches better the user's
expectation, then you have to rely on the filesystem API (e.g. stat).
One cannot state that stat() is not standard on one hand and expect an
information about something that C ignores (e.g. access rights) on the
other hand.

Yes you can, it just means that you have to go to something outside the
C standard to achieve it, be that the Posix standard or some other
extension.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

[Kenneth Brody]

Keith Thompson wrote:

Kenneth Brody <ke******@spamcop.net> writes:

Keith Thompson wrote:
[...]

Usually the best approach is to try to open the file, and handle the
error if the attempt fails. Providing information about *why* it
failed can be useful, but it isn't absolutely necessary, and it can't
be done portably.

Isn't this portable?

... proper #include's, etc. implied ...

errno=0;
f = fopen(filename,mode);
if ( f == NULL )
{
if ( errno != 0 )
perror(filename);
else
fprintf(stderr,"fopen() of %s failed.\n",filename);
exit(EXIT_FAILURE);
}

No, since the standard doesn't say that fopen() sets errno on failure.
perror() could print something silly like "foo.txt: No error", or
"foo.txt: File exists".

Hence the "errno=0" prior to fopen(), and the check for "errno != 0"
prior to calling perror().

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Kenneth Brody]

Flash Gordon wrote:

Kenneth Brody wrote:

Keith Thompson wrote:
[...]

Usually the best approach is to try to open the file, and handle the
error if the attempt fails. Providing information about *why* it
failed can be useful, but it isn't absolutely necessary, and it can't
be done portably.

Isn't this portable?

... proper #include's, etc. implied ...

errno=0;
f = fopen(filename,mode);
if ( f == NULL )
{
if ( errno != 0 )
perror(filename);
else
fprintf(stderr,"fopen() of %s failed.\n",filename);
exit(EXIT_FAILURE);
}

It's portable, but it might always print out "fopen() of %s failed.\n"
and never give a reason on some implementations.

Which I suppose qualifies for "can't be done portably" in terms of
actually getting the reason. However, the above is portable, and
will give the reason on those platforms that tell you why. On
platforms that don't tell you why, there's not much that you can
do, is there? (Even non-portably. Unless the "real" error number
is stored somewhere, but not placed in errno, sort of like the
Windows GetLastError() call. Of course, all the Windows C compilers
that I've seen set errno for you.)

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Michael Wojcik]

In article <ku************@news.flash-gordon.me.uk>, Flash Gordon <sp**@flash-gordon.me.uk> writes:

I disagree, does not exist and cannot be opened are very different concepts.

Always? I've seen filesystems where they're indistinguishable, such
as steganographic "deniable" filesystems where the proper key is
required to determine both the existence and contents of a particular
"file". Without that key, it's impossible to prove the existence or
nonexistence of the file.

Since it's completely possible to use such a filesystem under C's I/O
model (the "filename" passed to fopen becomes the key to the file),
there are potentially implementations for which there is no difference
between "does not exist" and "cannot be opened".

--
Michael Wojcik mi************@microfocus.com

As always, great patience and a clean work area are required for fulfillment
of this diversion, and it should not be attempted if either are compromised.
-- Chris Ware

[Flash Gordon]

Michael Wojcik wrote:

In article <ku************@news.flash-gordon.me.uk>, Flash Gordon <sp**@flash-gordon.me.uk> writes:

I disagree, does not exist and cannot be opened are very different concepts.
Always? I've seen filesystems where they're indistinguishable, such
as steganographic "deniable" filesystems where the proper key is
required to determine both the existence and contents of a particular
"file". Without that key, it's impossible to prove the existence or
nonexistence of the file.

My opinion is that your inability to see something does not change its
existence. So I would say that running under such a system just makes it
impossible to use non-standard means to determine if a file exists, that
does not translate in to the file not existing if you can't open it (or
tell it exists) because you don't have the key.
Since it's completely possible to use such a filesystem under C's I/O
model (the "filename" passed to fopen becomes the key to the file),
there are potentially implementations for which there is no difference
between "does not exist" and "cannot be opened".

With a system where it is guaranteed that no looking or permissions will
prevent you from opening a file then if you can't open a file it doesn't
exist. However, that *still* does not make the two concepts different,
it just makes detecting whether a file exists easy on *that* implementation.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php

[Keith Thompson]

Kenneth Brody <ke******@spamcop.net> writes:

Keith Thompson wrote:

Kenneth Brody <ke******@spamcop.net> writes:

> Keith Thompson wrote:
> [...]
>> Usually the best approach is to try to open the file, and handle the
>> error if the attempt fails. Providing information about *why* it
>> failed can be useful, but it isn't absolutely necessary, and it can't
>> be done portably.
>
> Isn't this portable?
>
> ... proper #include's, etc. implied ...
>
> errno=0;
> f = fopen(filename,mode);
> if ( f == NULL )
> {
> if ( errno != 0 )
> perror(filename);
> else
> fprintf(stderr,"fopen() of %s failed.\n",filename);
> exit(EXIT_FAILURE);
> }

No, since the standard doesn't say that fopen() sets errno on failure.
perror() could print something silly like "foo.txt: No error", or
"foo.txt: File exists".

Hence the "errno=0" prior to fopen(), and the check for "errno != 0"
prior to calling perror().

No, it's still not 100% portable (i.e., it's not guaranteed by the
standard). A failing fopen() could legally set errno to a non-zero
value that has nothing to do with the reason the fopen() call failed.
I presented a (rather implausible) example elsewhere in this thread.

I suspect that most real implementations set errno to something
meaningful, but it's not required.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Kenneth Brody]

Keith Thompson wrote:

Kenneth Brody <ke******@spamcop.net> writes:

Keith Thompson wrote: [...] Hence the "errno=0" prior to fopen(), and the check for "errno != 0"
prior to calling perror().
No, it's still not 100% portable (i.e., it's not guaranteed by the
standard). A failing fopen() could legally set errno to a non-zero
value that has nothing to do with the reason the fopen() call failed.
I presented a (rather implausible) example elsewhere in this thread.

I know that the standard doesn't guarantee that fopen() will set errno
on failure. But does it really allow it to change errno to a non-zero
value that's not the actual error? Is this a "legal" implementation
within fopen()?

...
if ( it_failed )
{
errno = rand();
return(NULL);
}
...

Okay, so someone will probably point out that it's not allowed to call
rand() for some reason. :-)

So how about:

if ( it_failed )
{
errno = (int)time(NULL);
return(NULL);
}
I suspect that most real implementations set errno to something
meaningful, but it's not required.

Well, does "99.99% portable" qualify? :-)

I wonder if someone wants to implement a C environment where it does
all of the "legal, but probably not taken into account" behaviors?
Things like setting errno to something other than the "real" value,
or randomly zeroing memory on "a[i] = i++".

No, this is not me volunteering to do so. :-)

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Michael Wojcik]

In article <fi************@news.flash-gordon.me.uk>, Flash Gordon <sp**@flash-gordon.me.uk> writes:

Michael Wojcik wrote:

In article <ku************@news.flash-gordon.me.uk>, Flash Gordon <sp**@flash-gordon.me.uk> writes:

I disagree, does not exist and cannot be opened are very different concepts.
Always? I've seen filesystems where they're indistinguishable, such
as steganographic "deniable" filesystems where the proper key is
required to determine both the existence and contents of a particular
"file". Without that key, it's impossible to prove the existence or
nonexistence of the file.

My opinion is that your inability to see something does not change its
existence.

Fine, but there's quite a gulf between "your inability to see
something" and "it's impossible to prove the existence or
nonexistence".
So I would say that running under such a system just makes it
impossible to use non-standard means to determine if a file exists,
It's impossible to determine whether a file exists (in principle;
in practice, there are a finite, albeit very large, number of
possible keys, so you can brute-force it), full stop.
that
does not translate in to the file not existing if you can't open it (or
tell it exists) because you don't have the key.

If there's no decision procedure that can distinguish between two
conditions, on what basis do you decide those conditions are
distinct?

With a steganographic deniable filesystem, it's always possible
that a "file" you do succeed in opening is actually just a random
artifact of a combination of the filesystem data and key; it may
not have been created "on purpose" at all. The probability of
such an accidental file diminishes as the file's entropy
increases, of course, but in theory you could find any finite
file in a sufficiently large SD filesystem just by choosing the
appropriate key. (Obviously the key length has to grow in order
to select the necessary "file", by the pigeonhole principle.)

The whole point of an SD filesystem is to erase the distinction
between "does not exist" and "cannot be found (opened, etc)". Any
meaningful message is just some transformation of noise - SD
filesystems keep the noise and make you remember (in a compressed
form, in practice) the transformation.

--
Michael Wojcik mi************@microfocus.com

Memory, I realize, can be an unreliable thing; often it is heavily coloured
by the circumstances in which one remembers, and no doubt this applies to
certain of the recollections I have gathered here. -- Kazuo Ishiguro

[Keith Thompson]

Kenneth Brody <ke******@spamcop.net> writes:

Keith Thompson wrote:

Kenneth Brody <ke******@spamcop.net> writes:

> Keith Thompson wrote: [...] > Hence the "errno=0" prior to fopen(), and the check for "errno != 0"
> prior to calling perror().
No, it's still not 100% portable (i.e., it's not guaranteed by the
standard). A failing fopen() could legally set errno to a non-zero
value that has nothing to do with the reason the fopen() call failed.
I presented a (rather implausible) example elsewhere in this thread.

I know that the standard doesn't guarantee that fopen() will set errno
on failure. But does it really allow it to change errno to a non-zero
value that's not the actual error? Is this a "legal" implementation
within fopen()?

...
if ( it_failed )
{
errno = rand();
return(NULL);
}
...

Okay, so someone will probably point out that it's not allowed to call
rand() for some reason. :-)

Right.
So how about:

if ( it_failed )
{
errno = (int)time(NULL);
return(NULL);
}
Yes, and something like it is even plausible.

Suppose the implementer decided not to have fopen() set errno to a
meaningful value on an error, because the standard doesn't require it.
But fopen() is implemented on top of lower-level routines, some of
which do set errno. One of those routines might fail for reasons
having nothing to do with the failure of fopen().

For example, suppose fopen("foo.txt", "w") calls a routine (similar to
the Unix stat() function) that gets information about an existing
file; if the file doesn't exist, it fails and sets errno to EEXIST
("No such file or directory"). (EEXIST isn't defined by the C
standard, but we'll assume it's defined by the implementation).
fopen() now knows that the file doesn't exist, so it attempts to
create it. The attempt fails because, say, the user doesn't have
write permission on the current directory -- but the routine that
attempts to create the file doesn't set errno. Perhaps it just
returns a null pointer, or uses some other mechanism to report errors.

The net result is that fopen("foo.txt", "w") fails with errno set to
EEXIST, implying that the attempt to create the file failed because
the file doesn't exist (!).

This scenario is unlikely to happen in real life; if the stat()-like
function sets errno properly, chances are the file creation function
does so as well. But it's allowed by the standard.

As I mentioned elsethread, this kind of problem could have been
avoided by requiring all functions defined in the standard library, on
failure, *either* to set errno to some meaningful value, *or* to reset
it to its previous value. Or by requiring all standard library
functions to set errno to some meaningful value, and defining EERROR
as a generic unknown error indication.

I suspect that most real implementations set errno to something
meaningful, but it's not required.

Well, does "99.99% portable" qualify? :-)

Serious answer: Does it qualify as what? Does it qualify as 100%
portable? No. Does it qualify as good enough for your purposes?
That's entirely up to you.
I wonder if someone wants to implement a C environment where it does
all of the "legal, but probably not taken into account" behaviors?
Things like setting errno to something other than the "real" value,
or randomly zeroing memory on "a[i] = i++".

No, this is not me volunteering to do so. :-)

Like a real-life DS9K? That would be a handy thing to have.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Flash Gordon]

Michael Wojcik wrote:

In article <fi************@news.flash-gordon.me.uk>, Flash Gordon <sp**@flash-gordon.me.uk> writes:

Michael Wojcik wrote:

In article <ku************@news.flash-gordon.me.uk>, Flash Gordon <sp**@flash-gordon.me.uk> writes:
I disagree, does not exist and cannot be opened are very different concepts.
Always? I've seen filesystems where they're indistinguishable, such
as steganographic "deniable" filesystems where the proper key is
required to determine both the existence and contents of a particular
"file". Without that key, it's impossible to prove the existence or
nonexistence of the file. My opinion is that your inability to see something does not change its
existence.

Fine, but there's quite a gulf between "your inability to see
something" and "it's impossible to prove the existence or
nonexistence".

Whether or not you can prove its existence still doesn't affect whether
it exists or not. I run a number of Linux boxes, and even if I gave you
a user account on one of them you still could not tell whether the file
/root/t.txt exists. This does not affect its existence.

So I would say that running under such a system just makes it
impossible to use non-standard means to determine if a file exists,

It's impossible to determine whether a file exists (in principle;
in practice, there are a finite, albeit very large, number of
possible keys, so you can brute-force it), full stop.

So? I have already stated that there may not be a way to prove whether
or not a file exists. It still either exists or does not exist. Unless
you are using quantum storage in which case, like Schrodinger's cat, it
might both exist and not exist at the same time.

that
does not translate in to the file not existing if you can't open it (or
tell it exists) because you don't have the key.

If there's no decision procedure that can distinguish between two
conditions, on what basis do you decide those conditions are
distinct?

So? There is no way for you to determine whether my brother's wife's
uncles house has a second story. Does that affect whether or not it exists?
With a steganographic deniable filesystem, it's always possible
that a "file" you do succeed in opening is actually just a random
artifact of a combination of the filesystem data and key; it may
not have been created "on purpose" at all. The probability of
such an accidental file diminishes as the file's entropy
increases, of course, but in theory you could find any finite
file in a sufficiently large SD filesystem just by choosing the
appropriate key. (Obviously the key length has to grow in order
to select the necessary "file", by the pigeonhole principle.)

The whole point of an SD filesystem is to erase the distinction
between "does not exist" and "cannot be found (opened, etc)". Any
meaningful message is just some transformation of noise - SD
filesystems keep the noise and make you remember (in a compressed
form, in practice) the transformation.

So? The information still either exists or does not exist. Just because
you or I can't prove whether or not it exists doesn't change that. Even
if the key is lost forever the information is still encoded there until
it is overwritten.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php

[Kenneth Brody]

Keith Thompson wrote:

Kenneth Brody <ke******@spamcop.net> writes: [...]

if ( it_failed )
{
errno = (int)time(NULL);
return(NULL);
}

Yes, and something like it is even plausible.

Suppose the implementer decided not to have fopen() set errno to a
meaningful value on an error, because the standard doesn't require it.
But fopen() is implemented on top of lower-level routines, some of
which do set errno. One of those routines might fail for reasons
having nothing to do with the failure of fopen().

[... fopen() using stat() to test existence ...] The net result is that fopen("foo.txt", "w") fails with errno set to
EEXIST, implying that the attempt to create the file failed because
the file doesn't exist (!).

This scenario is unlikely to happen in real life; if the stat()-like
function sets errno properly, chances are the file creation function
does so as well. But it's allowed by the standard.
True, since the Standard doesn't specify how fopen() actually opens
the file, though it's probably via the "non-Standard" open() call.

Thanks for a plausible, yet still unlikely, scenario.

I have run into cases where fopen() would fail, even though the
low-level open() call succeeded. Sometimes, malloc'ing the buffer
would fail, so even though the file was "open", it would return NULL,
and errno would be "out of memory". Other times, the runtime library
was limited to X open FILEs, while the O/S was set to allow Y (where
Y>X) open files. So, the open() call would succeed, and then the
runtime library would fail because there was no FILE to stick it in.
(In this case, I think errno was left unchanged.)
As I mentioned elsethread, this kind of problem could have been
avoided by requiring all functions defined in the standard library, on
failure, *either* to set errno to some meaningful value, *or* to reset
it to its previous value. Or by requiring all standard library
functions to set errno to some meaningful value, and defining EERROR
as a generic unknown error indication.

I think "resetting it to its previous value" would add too much
overhead to the library, as it would require _every_ failable function
to save/restore it. However, requiring that it set errno on failure,
even to some generic "EERROR" if needed, would be useful.

I suspect that most real implementations set errno to something
meaningful, but it's not required.

Well, does "99.99% portable" qualify? :-)

Serious answer: Does it qualify as what? Does it qualify as 100%
portable? No. Does it qualify as good enough for your purposes?
That's entirely up to you.

:-)

I wonder if someone wants to implement a C environment where it does
all of the "legal, but probably not taken into account" behaviors?
Things like setting errno to something other than the "real" value,
or randomly zeroing memory on "a[i] = i++".

No, this is not me volunteering to do so. :-)

Like a real-life DS9K? That would be a handy thing to have.

I think the C compiler would be easier to build in real-life, however.

They have test suites to verify a compiler's adherence to the Standard,
so why not a compiler that stress-tests C source?

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Kenneth Brody]

Michael Wojcik wrote:
[... "failed to open" vs. "file doesn't exist" ...]

With a steganographic deniable filesystem, it's always possible
that a "file" you do succeed in opening is actually just a random
artifact of a combination of the filesystem data and key; it may
not have been created "on purpose" at all. The probability of
such an accidental file diminishes as the file's entropy
increases, of course, but in theory you could find any finite
file in a sufficiently large SD filesystem just by choosing the
appropriate key. (Obviously the key length has to grow in order
to select the necessary "file", by the pigeonhole principle.)

The whole point of an SD filesystem is to erase the distinction
between "does not exist" and "cannot be found (opened, etc)". Any
meaningful message is just some transformation of noise - SD
filesystems keep the noise and make you remember (in a compressed
form, in practice) the transformation.

Does this mean that, if you have the "right" filename, you can open it
in any mode whatsoever? There's no such thing as a read-only file?

(And, in any case, this is just a "special case" situation, which has
been designed to purposfully hide such distinctions.)

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Mark McIntyre]

On Thu, 20 Apr 2006 21:29:43 +0100, in comp.lang.c , Flash Gordon
<sp**@flash-gordon.me.uk> wrote:

Michael Wojcik wrote:

Fine, but there's quite a gulf between "your inability to see
something" and "it's impossible to prove the existence or
nonexistence".
Whether or not you can prove its existence still doesn't affect whether
it exists or not.

Not to get metaphysical, but in point of fact its central.
I run a number of Linux boxes, and even if I gave you
a user account on one of them you still could not tell whether the file
/root/t.txt exists. This does not affect its existence.

In a very real sense, it /defines/ its state of existence. In this
case, indeterminate.

I'm guessing you're not a physicist, and don't have a cat. Or any
boxes.

Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Flash Gordon]

Mark McIntyre wrote:

On Thu, 20 Apr 2006 21:29:43 +0100, in comp.lang.c , Flash Gordon
<sp**@flash-gordon.me.uk> wrote:

Michael Wojcik wrote:

Fine, but there's quite a gulf between "your inability to see
something" and "it's impossible to prove the existence or
nonexistence".

Whether or not you can prove its existence still doesn't affect whether
it exists or not.

Not to get metaphysical, but in point of fact its central.

I run a number of Linux boxes, and even if I gave you
a user account on one of them you still could not tell whether the file
/root/t.txt exists. This does not affect its existence.

In a very real sense, it /defines/ its state of existence. In this
case, indeterminate.

I'm guessing you're not a physicist, and don't have a cat. Or any
boxes.

Well, unless you can prove that no one else is looking at the file that
might or might not exist, then the state of it's existence is still not
completely dependant on whether you can see it or not.

I do know a bit about cats, boxes and physics and the relationship
between them. Perhaps we should repeat the experiment with a file
containing a picture of a cat and a computer set up to delete the file
if the particle decays?
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php

[Michael Wojcik]

In article <mi************@news.flash-gordon.me.uk>, Flash Gordon <sp**@flash-gordon.me.uk> writes:

Michael Wojcik wrote:

In article <fi************@news.flash-gordon.me.uk>, Flash Gordon <sp**@flash-gordon.me.uk> writes:

Michael Wojcik wrote:
In article <ku************@news.flash-gordon.me.uk>, Flash Gordon <sp**@flash-gordon.me.uk> writes:
> I disagree, does not exist and cannot be opened are very different concepts.
Always? I've seen filesystems where they're indistinguishable, such
as steganographic "deniable" filesystems where the proper key is
required to determine both the existence and contents of a particular
"file". Without that key, it's impossible to prove the existence or
nonexistence of the file.
My opinion is that your inability to see something does not change its
existence.
Fine, but there's quite a gulf between "your inability to see
something" and "it's impossible to prove the existence or
nonexistence".

Whether or not you can prove its existence still doesn't affect whether
it exists or not.

Sigh. Whether or not *I* can prove the existence of something is
very different from whether or not it's possible *in general* to
prove the existence of something.

The existence of an entity whose existence cannot be demonstrated is
a question for metaphysics. It's not at all certain that existence
is independent from proof (or demonstration).

So I would say that running under such a system just makes it
impossible to use non-standard means to determine if a file exists,

It's impossible to determine whether a file exists (in principle;
in practice, there are a finite, albeit very large, number of
possible keys, so you can brute-force it), full stop.

So? I have already stated that there may not be a way to prove whether
or not a file exists. It still either exists or does not exist.

Simply claiming that does not constitute an argument.

that
does not translate in to the file not existing if you can't open it (or
tell it exists) because you don't have the key.

If there's no decision procedure that can distinguish between two
conditions, on what basis do you decide those conditions are
distinct?

So? There is no way for you to determine whether my brother's wife's
uncles house has a second story. Does that affect whether or not it exists?

Entirely irrelevant, as I noted above.

With a steganographic deniable filesystem, it's always possible
that a "file" you do succeed in opening is actually just a random
artifact of a combination of the filesystem data and key; it may
not have been created "on purpose" at all. The probability of
such an accidental file diminishes as the file's entropy
increases, of course, but in theory you could find any finite
file in a sufficiently large SD filesystem just by choosing the
appropriate key. (Obviously the key length has to grow in order
to select the necessary "file", by the pigeonhole principle.)

The whole point of an SD filesystem is to erase the distinction
between "does not exist" and "cannot be found (opened, etc)". Any
meaningful message is just some transformation of noise - SD
filesystems keep the noise and make you remember (in a compressed
form, in practice) the transformation.

So? The information still either exists or does not exist.

That's a tenuous position that's widely disputed. Do you have an
actual argument to make in favor of it, or is this just a blind
belief?
Just because
you or I can't prove whether or not it exists doesn't change that.
Let me try again: it is *impossible* for *anyone* to prove whether an
SD filesystem contains a given piece of information. Or considered
another way, an SD filesystem contains *all* messages of less than a
certain maximum entropy (where the amount of entropy is a function of
the size of the filesystem).
Even
if the key is lost forever the information is still encoded there until
it is overwritten.

That's a question of metaphysics, or of belief; it can't be positively
demonstrated.

--
Michael Wojcik mi************@microfocus.com

An intense imaginative activity accompanied by a psychological and moral
passivity is bound eventually to result in a curbing of the growth to
maturity and in consequent artistic repetitiveness and stultification.
-- D. S. Savage

[Michael Wojcik]

In article <44***************@spamcop.net>, Kenneth Brody <ke******@spamcop.net> writes:

Michael Wojcik wrote:
[... "failed to open" vs. "file doesn't exist" ...]

With a steganographic deniable filesystem, it's always possible
that a "file" you do succeed in opening is actually just a random
artifact of a combination of the filesystem data and key; it may
not have been created "on purpose" at all. The probability of
such an accidental file diminishes as the file's entropy
increases, of course, but in theory you could find any finite
file in a sufficiently large SD filesystem just by choosing the
appropriate key. (Obviously the key length has to grow in order
to select the necessary "file", by the pigeonhole principle.)

The whole point of an SD filesystem is to erase the distinction
between "does not exist" and "cannot be found (opened, etc)". Any
meaningful message is just some transformation of noise - SD
filesystems keep the noise and make you remember (in a compressed
form, in practice) the transformation.
Does this mean that, if you have the "right" filename, you can open it
in any mode whatsoever? There's no such thing as a read-only file?

That's an implementation detail. An SD filesystem could include
filesystem metadata in such a way that for a given message, there
might exist a key which produced that message plus metadata that
meant "read only" to the filesystem, but no key shorter than the
message itself which produced the message plus "read/write" metadata,
so in effect the file could only be opened read-only. Or it might be
implemented on read-only media, for that matter.
(And, in any case, this is just a "special case" situation, which has
been designed to purposfully hide such distinctions.)

Right, but my original point - that the distinction between "does not
exist" and "cannot be opened" doesn't always hold - only requires a
counterexample to that distinction.

There are other, less esoteric examples where a filesystem might not
be able to meaningfully distinguish those conditions. Secure file
access in general often obscures the distinction at the media-access
level, so the API couldn't return an error indicator that
distinguished them. A network filesystem often wouldn't be able to
tell whether a remote resource was unavailable or simply didn't
exist. And so on.

More generally, a "does not exist" indication cannot be completely
reliable, because that would require proving a negative. It can be
made arbitrarily reliable under specific constraints, but no
algorithm can ensure that a given message exists nowhere (except for
the special case of messages that provably cannot exist, like
compressed forms of Chaitin's omega, and it's dubious that those can
be said to constitute "messages" per se anyway). SD filesystems are
just a way of leveraging that doubt in practice.

--
Michael Wojcik mi************@microfocus.com

If Mokona means for us to eat this, I, a gentle person, will become
angry! -- Umi (CLAMP & unknown translator), _Magic Knight Rayearth_

[Walter Roberson]

In article <e2*********@news2.newsguy.com>,
Michael Wojcik <mw*****@newsguy.com> wrote:
[OT]

An SD filesystem could include
filesystem metadata in such a way that for a given message, there
might exist a key which produced that message plus metadata that
meant "read only" to the filesystem, but no key shorter than the
message itself which produced the message plus "read/write" metadata,
so in effect the file could only be opened read-only.

I don't see where the restriction to "no key shorter" would come in,
nor the relevance of that length to "in effect" make the file read-only?
If you had said "no key that did not include the message itself"
perhaps, but even then it doesn't sound right.

If I have a file on a SD filesystem that currently decodes to
1 byte, and I have a read-write key to it, then the extra 1 byte
you would impose is not a meaningful expansion of key space
sufficient to "in effect" make the file read-only. But once I
have a read-write key to the file and I write (say) 1 megabyte
there, the read-write keysize is not suddenly going to bloom
to more than a megabyte: the read-write key would stay the same.

It seems to me that any restriction that forced keys to be
larger than the files would impede the deniability. Isn't it the
case that for SD, -every- key should get -something-? If so,
then every read-write key would, in your "no shorter" proposal,
map through SD to a shorter value -- but that would, in effect,
be a compression function, and by the pigeon-hole principle
you can't have a compression function which uniquely maps every input
to a shorter output. Therefore if you have read-write keys, some of
them must be shorter than the file they allow to be written.

[This argument does not hold if some keys are "invalid". For example,
there is the trivial mapping that the read-write key is a byte of 0
followed by content, and that the value so accessed is the content
with the 0 stripped off; this does uniquely map each valid input,
but the cost of it is that keys that started with 1 to 255 in the
first byte could never be read-write keys.]
--
"It is important to remember that when it comes to law, computers
never make copies, only human beings make copies. Computers are given
commands, not permission. Only people can be given permission."
-- Brad Templeton