gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > Determine free file system space?

#104062 - bjoerngiesler - Tue Sep 26, 2006 8:15 am

Is there a way to determine the free file system space on a FAT-formatted card? I haven't found any so far...

TIA!
_________________
DSFTP homepage

#104070 - chishm - Tue Sep 26, 2006 10:51 am

Manually or through a library?

Manually:
Scan the FAT and add total the number of empty clusters, then multiply that by the number of bytes per cluster.

Through a library:
Not doable with gba_nds_fat or libfat. Is there even a POSIX function for this?
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

#104077 - bjoerngiesler - Tue Sep 26, 2006 11:40 am

chishm wrote:
Manually:
Scan the FAT and add total the number of empty clusters, then multiply that by the number of bytes per cluster.


Right. I had hoped there was a library call for this.

Quote:
Not doable with gba_nds_fat or libfat. Is there even a POSIX function for this?


Well, there is statfs(), which is in BSD and Linux.

http://linux.about.com/library/cmd/blcmdl2_statfs.htm

Not in POSIX, as far as I can see. Since such a call is very useful whether standard or not, would it be a lot of hassle to put it into the library nonetheless?

EDIT: It's in POSIX after all, it seems: http://www.rcsnet.net/c5-1.0/doc/html/ManPages/hman2posix/statfs.2posix.html. With a very different definition of struct statfs, though.
_________________
DSFTP homepage

#104128 - TJ - Tue Sep 26, 2006 6:33 pm

Certainly does seem like the kind of call that belongs in the lib.

#104243 - chishm - Wed Sep 27, 2006 11:30 am

Hmm, it's actually statvfs() now (statfs() is deprecated). Unfortunately it is pretty hard to add functionality to libfat, due to the requirement for calls to go through newlib (eg file listing).
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

#104296 - tepples - Wed Sep 27, 2006 9:09 pm

chishm wrote:
it is pretty hard to add functionality to libfat, due to the requirement for calls to go through newlib

You could implement things through something like the /proc file system in Linux, where the file system exposes a fake directory (or drive letter) that appears to contain text files. Likewise, you could set up reading from directories so that fopen("/", "r") returns a newline-delimited list of files in the folder, similar to what MS-DOS or Windows Command Prompt gives when you "dir /b".

Everything is a file.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#104362 - chishm - Thu Sep 28, 2006 10:41 am

Devices (as in, file systems, terminals, etc) in DevkitPro are given individual names, such as "fat:" or "stdin:". They are not all part of one directory tree.

Having libfat fake a /proc directory adds unnecessary complications to the file tree. "fat:/" is the root of the FAT device, not the root of the entire device tree. What happens if a "fat:/proc/" directory actually exists? It would be posible to add a second device to the device table specifically for "proc:", but what happens if another file system device driver tries to do the same?

If directories are treated as files then either only the filenames are readable as though it's a text file, or more data is obtainable through a proprietry format. Specific directory listing functions are much better.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

#104404 - tepples - Thu Sep 28, 2006 6:52 pm

chishm wrote:
Having libfat fake a /proc directory adds unnecessary complications to the file tree. "fat:/" is the root of the FAT device, not the root of the entire device tree. What happens if a "fat:/proc/" directory actually exists?

Then you could use a character in the pseudo-directory name that's not legal in an MS-FAT file name.

Quote:
It would be posible to add a second device to the device table specifically for "proc:", but what happens if another file system device driver tries to do the same?

But are there any other file system device drivers? However, I'm beginning to think you're right that a dedicated way to estimate free space on a volume should be added.

Quote:
If directories are treated as files then either only the filenames are readable as though it's a text file, or more data is obtainable through a proprietry format.

I was imagining a while loop with fgets() and stat().

Quote:
Specific directory listing functions are much better.

They're not "much better" if no version of devkitPro that uses them is available.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#104431 - chishm - Fri Sep 29, 2006 3:05 am

tepples wrote:
Quote:
Specific directory listing functions are much better.

They're not "much better" if no version of devkitPro that uses them is available.

If we're talking ugly hacks to get around the lack of DKP updates then I could just write temporary wrapper functions that call the FAT directory listing functions directly, rather than using the correct method of going through the device table.

For the curious, the functions that (will eventually) get called through the device table are in fatdir.h.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

#104435 - tepples - Fri Sep 29, 2006 4:08 am

chishm wrote:
I could just write temporary wrapper functions that call the FAT directory listing functions directly, rather than using the correct method of going through the device table.

IMHO, such wrappers would be at least as good as the old gba_nds_fat way of doing things. It's not unprecedented, as several file systems on Linux have various specialized syscalls that don't go through the VFS.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.