It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
I've got a lab work relating to Linux's File System. The thing is that I need to retrieve all directories and files in a floppy image.It is required using C language to get directories and filenames of an FAT12 formatted floppy image.
Below is what I've done by now:
I had created a floppy.img using linux dd command and add some files into it;
I had gathered some information about FAT12 file system and known how data arranged in a floppy disk;
Below is what I completely have no idea about:
I know little linux system call
Now I need your help for showing me the entry of solving this problem. Some hints or documents also do great help to me!
What you will need to do is to open your copied image in C. You will need to read this data in, understanding the FAT12 format, modify it, then write it back out.
Look at fopen, fread, fclose using "man". You will probably need to make an array of FAT structures, read in each FAT entry using fread, then modify your array with new entries and write it back out using fwrite. You will probably want to use fseek to jump around. I expect you want to write a new entry to the disk FAT table (sic) and also knowing where the free space is, write the actual file there.
1) fopen
2) fread FAT into arrays (using fseek as needed)
3) modify arrays with new entries
4) fwrite new files' data to the appropriate free area of the image
5) fwrite the updated array back to the FAT
6) fclose
7) test the image
You can test the image by something like this:
mkdir /mnt/test -p
mount -o loop -t vfat test.img /mnt/test
If this fails, then you messed up somewhere. Use hexdump to examine your file.
If it works, make sure to umount it before modifying the file again.
From what I understand you should read data from a disk image in a pure user-space program. In other words: you're not required to write any kernel code or driver.
This task is possible using only standard C API, no Linux-specific calls should be necessary.
I've written a complete implementation of this for a previous employer. Fortunately FAT is VERY well supported as binary formats and filesystems go.
The canonical reference for this is the Microsoft specification (FAT was conceived by Bill Gates in 1976), which covers FAT12, FAT16, and FAT32, which are all very similar.
As you are working in user space, the C stdio library will meet all your needs.
Related
So I have file system ext2 formatted image files. I like to view Inode, super block, filenames, etc. in the images for formatted file systsem . I like to know is there any tool for this. I need to view these structures like inode, superblock, file, related info like names of files, deleted inodes etc. In terminal, posssible some tool with available code in Linux. So can be editted the tool. Would be best if tool is coded in just C languange. Can anyone please do tell me this, Thanks again. Just opensource tool
I'm not certain I understood your question, but I think you probably just want to "loopback mount" your filesystem in a file. See here.
Failing that, I think you can use e2tools to access the contents. See here.
I want to open /dev/graphics/fb0 from kernel space and write to it to display a test pattern. Is there any way I can do that?
There is one question related to this. But, in the answer, it's done from user space, which I don't want.
I am using a program by using the linux kernel (in this case a predictor for protein localization). The output/results are printed in the linux kernel, one after each other. However, if I want to copy it to a simple textfile, the "length" of the kernel is not long enough for all the results.
instead of using smaller seperate files, I would like to print the output of the kernel to a file. I tried to google this, but it doesn't really help me futher.
1. dmesg seems to be for system-output stuff?
2. the /var/log/syslog.txt doesn't show the stuff I need, but other technical kernel stuff.
3. i saw something with printf(), but didn't quite understand the mechanics and if it was useable for my problem.
could someone explain how to do this or where to look for the right info?
I think i found out how to do it, by using > fileToBeNamed.txt at the end of the command, Sorry :(
As far as I am aware(correct me if I'm wrong), Linux is storing the information about each file's owner and permissions in a couple of bytes at the beginning of the file.
I know that there are plenty of ways to get that information about a file(both using shell commands and the GUI), but what I'm really wondering is if there is a way to access(view) those permissions in their raw form.
Maybe a more correct way to ask this question is whether there is a way to view the complete file contents(I've seen the binary output of a file using hexdump -C test.txt, but it still doesn't contain those) including the owner/permissions data.
I guess that this information is only accessed in it's raw form in deep-core code, but I'm really curious if it's possible to access it in a different way.
>>As far as I am aware(correct me if I'm wrong), Linux is storing the information about each file's owner and permissions in a couple of bytes at the beginning of the file.
NO!
This information is NOT stored in the file. It is a part of the filesystem's storage. Different file systems will store the binary data in different places. Some file systems will store in the information in the directory file. You should read more about filesystem permissions here, on Wikipedia
If you want to read permissions, since they are usually accessed from directory listings, look into the ls command.
If you really want to look at the "binary" data in it's "raw" form, look into opening and reading directory files in a programming language like C.
Recently, i began developing a driver of an embedded device running linux.
Until now i have only read about linux internals.
Having no prior experience in driver devlopment, i am finding it a tad difficult to land my first step.
I have downloaded the kernel source-code (v2.6.32).
I have read (skimped) Linux Device Drivers (3e)
I read a few related posts here on StackOverflow.
I understand that linux has a "monolithic" approach.
I have built kernel (included existing driver in menuconfig etc.)
I know the basics of kconfig and makefile files so that should not be a problem.
Can someone describe the structure (i.e. the inter-links)
of the various directories in the kernel-source code.
In other words, given a source-code file,
which other files would it refer to for related code
(The "#include"-s provide a partial idea)
Could someone please help me in getting a better idea?
Any help will be greatly appreciated
Thank You.
Given a C file, you have to look at the functions it calls and data structures it uses, rather than worrying about particular files.
There are two basic routes to developing your own device driver:
Take a driver that is similar to yours; strip out the code that isn't applicable to your device, and fill in new code for your device.
Start with the very basic pieces of a device driver, and add pieces a little at a time until your device begins to function.
The files that compose your driver will make more sense as you complete this process. Do consider what belongs in each file, but to some extent, dividing a driver among files is more an art than a science. Smaller drivers often fit into just one or two files.
A bit of design may also be good. Consider what you device does, and what your driver will need to do. Based on that, you should be able to map out what functions a device driver will need to have.
I also believe Linux Device Drivers, Third Edition may help you get on your way to driver development.
Linux files themselves include files based on what they do, what layer they are in, and what layer they access of the call stack. The Big Picture truly informs how each file is related to the next.
I had to fix a kernel driver once. My biggest tip (if you use vim) is to set it up with ctags so you can jump around the kernel source with ctrl-] every time you see a function you don't understand.