why is there no list of all methods of the File class in the References?

hi,
why is there no list of all methods of the File class in the References?
e.g. one can find FileRead Arduino - FileRead
but what is all the rest? (e.g. open, close, write, print, seek, append, search, get, unget, scan, whatelse)
Searching for "File class" shows nothing meaningful!

Is that it? You’d be amazed at what isn’t listed in the references. For that matter, you’d be amazed at what isn’t listed in all the texts written on C or C++. Sometimes you just have to get your feet wet and go wading through all the library headers. I’ve been doing this for almost 50 years now and just last week I discovered a function, __builtin_popcount(), that I never knew existed. Keep looking, keep learning.

What's wrong with this one?

https://www.arduino.cc/en/Reference/SD

BTW: I found that by googling "Arduino File" and looking at the third link it got. I wish people would put in just a tiny bit of effort looking before they come claim that something isn't there. Took me less than 15 seconds to find.

Isn’t it way more cool to ask in the Forum and have someone else do all that tedious Googling for you?

The SD page that lists all the methods of File class is also accessible by clicking the SD link at the top of the FileRead page, which brings you to the same page DeltaG posted....

I googled Arduino File class but there was no link to an observable File methods overview link at all.
And I never got the idea to look beyond SD if I wanted a File class methods overview, finally also FilerRead was listed beyond references, not beyond SD.
But thank you, this SD link is exactly what I was searching!

update,

why are
open() ,
exists(),
and
remove()
SD methods, and not File methods?

same to
mkdir()
rmdir()

It’s not like anything other than SD uses the file functions...

Huh. The SD methods don’t use the private data of the File class. They operate on the SD (file system as a whole) and a filename. It does seem particularly odd that open() is an SD method while openNextFile() is a file method, but I guess it’s consistent.

ok, hmmh, as I see everything is very different from fopen, fclose, fputs, fgets, fread, fscanf, fprintf, fwrite, fseek, fsetpos... :-/
tbh, a bit puzzling and weird...

dsyleixa:
ok, hmmh, as I see everything is very different from fopen, fclose, fputs, fgets, fread, fscanf, fprintf, fwrite, fseek, fsetpos... :-/
tbh, a bit puzzling and weird...

[sarcasm]Yeah, incredibly puzzling and weird to have to just take the letter f off of the function name. How could anyone ever figure out how close relates to fclose and how write relates to fwrite. That is so terribly obscure. It's like they're spelled completely differently with that one extra letter and all. [/sarcasm]

it was about the syntax, e.g. just 2 or 3 examples:

FILE is a pointer to stream, returning different pointers for either different file,
whilst file and SD are different classes, not specifying what to use (or how) for more than 1 file or SD.

FILE * fopen ( const char * filename, const char * mode );
for success returns a pointer to the file of the assigned filename, which was opened for read or write or append or update, and for write it creates a new one, of course starting from position 0, and for no success it returns a null pointer,
whilst
SD.open(filepath, mode) (not file.open !) with FILE_WRITE it appends at the end, not at the beginning, and does not rewrite, and it returns nothing about success or not.

int fclose ( FILE * stream ); gets passed the pointer to the file, and returns 0 for success or EOF for no success,
whilst
file.close() gets no file pointer and no file name passed to it to identify the actual file, and also no return of success or not.

That was what I meant.

So what part of that is so confusing? Looks like you’ve got it figured out. I’m sorry that big computers work differently from little microcontrollers. That’s just how it is.

yes, at the first glance it was puzzling because I thought C functions are equal, and some things are still unclear, but I'll see.

dsyleixa:
because I thought C functions are equal

That doesn't make any sense.

Here's another example, there are c functions that you might use on your PC when writing a program to display things to a screen. The Arduino doesn't have those functions either, because it doesn't have a screen. You have to use Serial to communicate with some other device (a PC usually) which does have a screen.

It shouldn't really be any surprise that a device with no file system doesn't have functions for manipulating a file system. Why in the world would it have functions to use something it doesn't have? That would be beyond stupid. Instead, it has a class to deal with SD cards. Again, you are limited to communicating with some other device that does the thing, in this case the SD card has a file system and you are communicating with it (via SPI) to tell it what to do with its file system. Why would you use a function like fopen for that when what you're really doing is communications stuff and not file system stuff?

This is like asking why my car doesn't have rudder controls like my boat. Because the car doesn't have a rudder. What good would rudder controls be?

now do not push things to extremes.
fopen, fclose, fwrite and so on are simple stdio functions which are - or should be - universal for either C compiler to either platform. At least I supposed them to be. IIUC, it's completely surprising that there is not even a file system existing - that's new to me, too (as to: for C, "anything is a file").

They are universal And they are for manipulating file systems. A microcontroller like the one on an Arduino doesn't have a file system. It doesn't have any place to store a file. So why would it have a file system? That just doesn't make any sense.

You are conflating a PC computer operating system with a file system with a microcontroller which is communicating with an SD card. The t wo are NOT equivalent. Here we have no operating system, no file system, only a means of communication with some external piece of equipment (the SD card) and it does file stuff.

Again, it's just like asking why my car doesn't have rudder controls.

I mean if there was an fopen on the Arduino, what would you have it do? Open a file? From where? There are no files on an Arduino.

Just like if there was a rudder control on my car what would you have it do? Control a rudder? There's no rudder.

as to: "I mean if there was an fopen on the Arduino, what would you have it do? Open a file? From where? There are no files on an Arduino."

Although I recognize that there are drawbacks on small MCUs, I sort of disagree about your fopen example:

there is a storage medium (SD), and it's formatted by a FAT file system, it contains files readable both on a PC and on the Arduino, so finally: what is ambiguous or false about fopen to files? just open them by fopen, on either platform, or read, or write, or close them.
If Arduinos are missing a file system, one might create one if it didn't exist yet.
But as stated, I see that there are drawbacks, and I'll certainly have to deal with them.

The SD is a peripheral device that you are sometimes going to have and that your processor isn’t in direct control of. Why can’t you understand that this is a completely different situation from a PC with an operating system? The Arduino CAN’T open files on the SD in the same sense that a PC can. All Arduino can do is ask the SD card to open the file and read it back.

It’s like the difference between picking up a book and reading it or having someone else read it to you. They are two completely different processes and you don’t do them both the same way. In one case you use your eyes andnin the other you use ears.

ok, I agree that I don't understand the differences about SD files read by a PC vs. read by an Arduino, and/or why one can't have a file system on Arduino, but I am no computer scientist - either way it appears to me just using C code with or without stdio commands.