Skip to main content

Know Mounted File System Type getmntent() Usage

I want to know the mounted file system type on my linux box, I got one useful stuff called getmntent(); which returns me the struct mntent, which contains the required information.
check out the usage of getmntent().

First one has to use setmntent();
The setmntent() function opens the file system description file fp and returns a file pointer which can be used by getmntent().
Syntax: FILE *setmntent(const char *filename, const char *type);

Then call for getmntent(),
The getmntent() function reads the next line from the file system description file fp and returns a pointer to a structure containing the broken out fields from a line in the file. The pointer points to a static area of memory which is overwritten by subsequent calls to getmntent().
syntax: struct mntent *getmntent(FILE *fp);
The mntent structure is defined in as follows:

struct mntent {
char *mnt_fsname; /* name of mounted file system */
char *mnt_dir; /* file system path prefix */
char *mnt_type; /* mount type (see mntent.h) */
char *mnt_opts; /* mount options (see mntent.h) */
int mnt_freq; /* dump frequency in days */
int mnt_passno; /* pass number on parallel fsck */
};
/etc/fstab file system description file
/etc/mtab mounted file system description file

Here is simple c program which i tried on linux box running on ARM9 processor.
#include
#include
#include
#include
#include

int main(void)
{
FILE *f = setmntent("/etc/mtab", "r");
struct mntent *m;

while ((m = getmntent(f))) {
struct stat st;
dev_t dev = 0;
if (stat(m->mnt_dir, &st) == 0) {
dev = st.st_dev;
}
printf("%s %s %s 0x%llx\n",
m->mnt_fsname, m->mnt_dir, m->mnt_type, (unsigned long long)dev);
}

endmntent(f);
return 0;
}
compile the program as
$ arm-linux-gcc disk1.c

I have connected two mass storage devices one of type FAt32 and one of type EXT3.

The output I got is
# ./a.out
/dev/ram1 /rdisk0 minix 0x101
none /proc/bus/usb usbfs 0xb
/dev/ram1 /rdisk0 minix 0x101
none /proc/bus/usb usbfs 0xb
/dev/sda4 /mnt/WD_800BEVSExternal_575845373036343130393738_4 vfat 0x804
/dev/sda1 /mnt/WD_800BEVSExternal_575845373036343130393738_1 ext3 0x801
Any suggestions.

Comments

Popular posts from this blog

Dotnet, .Net 3.5, 2.0, C# Interview Questions

Few questions on dotnet, C# 2.0, 3.5 On Object oriented concepts 1)What is inheritance with e.g 2)What is polymorphism -function overloading -Function overriding -virtual keyword use -Static keyword and use -Abstract classes -Interface -Object 3)What is threading and how do we use in realtime application(cognizant) 4)What is threadpooling, lock, monitor(write code sample) 5)Architecture of current project 6)Session state, diffrent types of state management. 7)What is Application_Start, how it works. 8)Type of authentication in asp.net 9)How to configure ASP.NET application. 10) What is Impersonation. 11) What is WebService, WSDL, UDDI, Discovery, asmx files. 12) How to implement WebService and use it. 13) When to use WebServices. 14) WPF, how to implement(BOA) 15) Testing concvepts. 16) Test attributes 17) Flow of Automation Test Method execution 18) Features of dotnet 3.5 19) CLR, garbage collection 20) Finally block 21) Manifest, Metadata, MSIL 22) Assemblies, Type of assemblies, str...

Remote debugging for ARM target board

Remote debugging for ARM target board With GDB one can both trace and modify code and data flow, and otherwise analyze the behavior of code, without explicitly changing any of it. Rather than run a full-blown instance of GDB on the target platform, you can use GDBserver , a program that lets you run GDB on a different machine than the one on which your program is running. The advantage of using GDBserver is that it needs just a fraction of the target resources that GDB consumes, because it implements only the low-level functionality of the debugger -- namely setting breakpoints and accessing the target processor registers and read/write application memory. GDBserver takes control of the application being debugged, and then waits for instructions from a remote instance of GDB running on a development workstation. Remote target needs to have debugging stub (gdbserver), The gdbserver is also referred to as the 'stub' and must be cross-compiled for that targ...