I have disk.img which is a fat32 file system in Linux. I want to reach its FAT and figure out used blocks for each file. I've read
http://wiki.osdev.org/FAT#FAT_32_3 but did not understand how to reach the table. Maybe I'm missing something.
How can I reach the FAT?
You need to read the boot sector. Once you have that information http://wiki.osdev.org/FAT#Reading_the_Boot_Sector tells how to reach the FAT:
The first sector in the File Allocation Table:
first_fat_sector = fat_boot->reserved_sector_count;
Related
I have written my own cp function which copies only half of the mp4 file from one partition to my own additionally created partition. This additionally created partition is half of the size of mp4 file and i am playing mp4 file from this partition.
After this half mp4 file is played, i want to remove the blocks of this part of a file so that I can copy the rest of the file to this partition and play it.
I am using low level i/o functions open,read,write,close in C file handling to write cp function.
This functionality is going to be dependant on the OS you are using. I am not aware of a universal way to do this. On windows, you can use the function _chsize() in unix based systems you want ftruncate(). you can use each of these functions to set the size of the file to 0, effectively getting rid of your allocated blocks.
I would use mmap(2) for that purpose and get rid of the scratch partition. On most systems, this is way faster since disk I/O is handled in the fashion that is just like swap file, which is very highly optimized and accerlerated.
When start playing, map the first portion of the file to a memory address and start working from that. Then when the end of the current part is coming map the next part in.
I've been experimenting with the performance of reading and writing files on Linux, specifically O_DIRECT, and I'm wondering, both at a hard drive level and the posix/Linux API level, is it possible to write only a few bytes to a sector, without destroying the rest of the sector, and without reading it first?
My experience with disk drives is that they expect data to be sent to them in entire sectors. So, basically, there's no way of writing less than an entire sector and if you wish to change the start of a sector without changing the end, you must read the whole sector, modify and write back. That is partly to do with how the disk head interacts with the platter (for physical disks anyway. In the case of flash drives, it's more likely to be with how small a chunk of the flash can be erased in one go).
In a portable way? Probably not.
In Linux and a few other Unix-like systems, you can open the block device for the drive, seek to a position (probably aligned to the sector size) and write some data to it, but I don't know what effect it would have on the remaining portion of that block.
Your best bet is to try it out on a virtual machine and see what happens. (Obviously, you'll have to have permission to write to the block device.)
I made a C program for school which allow me to write directly a message on a floppy disk sector in FAT. I manage to read this message corretly but the question asks me if I can read it after formatting it into EXT2.
So I would like to know if it is possible or not and why ?
I tested myself and I can't read the message but i don't know if it's good.
Thanks
Have you made a hexdump -C /dev/sdX of your disk before and after your formatting?
It would be interesting to view the difference, I think.
Concerning your outcome so far, according to this article on analyzing the ext2 filesystem, the data on your floppy would begin by 1024 bytes of zeros that make up the boot block. Then would follow the superimportant superblock.
Assuming a sectorsize of 512 bytes (I don't know how probable that is for your setting) your message was indeed overwritten by the ext2-superblock. Honorable end!
There's an AudioFileOpenURL function which opens an file. With AudioFileReadPackets that file is accessed to read packets. But one thing that stucks in my brain is: Does AudioFileOpenURL actually load the whole monster into memory? Or is that a lightweight operation?
So is it possible to read data from a file, only a specific portion, without having the whole terabytes of stuff in memory?
Does AudioFileOpenURL actually load the whole monster into memory?
No, it just gets you a file pointer.
Or is that a lightweight operation?
Yep, fairly lightweight. Just requires a filesystem lookup.
So is it possible to read data from a file, only a specific portion, without having the whole terabytes of stuff in memory?
Yes, you can use fseek to go a certain point in the file, then fread to read it into a buffer (or AudioFileReadBytes).
No, it doesn't load the entire file into memory. "Opens a file" returns a handle to you allowing you to read from or write to a file.
I don't know about objective-c, but with most languages you open the file, and that just gives you the ability to THEN access the contents with a READ operation. In your case, you can perform a SEEK to move the file pointer to the desired location, then read the number of bytes you need.
AudioFileOpenURL will open(2) the file and read the necessary info (4096 bytes) to determine the audio type.
open(2) won't load the whole file into RAM.
(AudioFileOpenURL is a C API, not Objective-C.)
This is a continuation of my question about reading the superblock.
Let's say I want to target the HFS+ file system in Mac OS X. How could I read sector 2 of the boot disk? As far as I know Unix only provides system calls to read from files, which are never stored at that location.
Does this require either 1) the program to run kernel mode, or 2) the program to be written in Assembly? I would prefer to avoid either of these restrictions, particularly the latter.
I've done this myself on the Mac, see my disk editor tool: http://apps.tempel.org/iBored
You'd open the drive using the /dev/diskN or /dev/rdiskN (N is a disk index number starting from 0). Then you can use lseek (make sure to use the 64 bit range version!) and read/write calls on the opened file.
Also, use the shell command "ls /dev/disk*" to see which drives exist currently. And note that the drives also exist with a "sM" extension where M is the partition number. That way, could can also read partitions directly.
Or, you could just use the shell tool "xxd" or "dd" to read data and then use their output. Might be easier.
You'll not be able to read your root disk and other internal disks unless you run as root, though. You may be able to access other drives as long as they were mounted by the user, or have their permissions disabled. But you may also need to unmount the drive's volumes first. Look for the unmount command in the shell command "diskutil".
Hope this helps.
Update 2017: On OS X 10.11 and later SIP may also prevent you from directly accessing the disk sectors.
In Linux, you can read from the special device file /dev/sda, assuming the hard drive you want to read is the first one. You need to be root to read this file. To read sector 2, you just seek to offset 2*SECTOR_SIZE and read in SECTOR_SIZE bytes.
I don't know if this device file is available on OS X. Check for interestingly named files under /dev such as /dev/sda or /dev/hda.
I was also going to suggest hitting the /dev/ device file for the volume, but you might want to contact Amit Singh who has written an hfsdebug utility and has probably done just what you want to do.
How does this work in terms of permissions? Wouldn't reading from /dev/... be insecure since if you read far enough you would be able to read files for which you do not have read access?