Questions related to Project 6

New questions will be put at the top.

    Added 12/1:

  • New specification regarding output directory:
    • You need to write a program called runScan that takes two arguments , a file that contains the disk image and an output directory where your output files will be stored.
    % ./runScan anImageDisk outputDirectory
    When your program starts, your program should create the specified output directory. If the directory already exists, print an error message (any message) and exit the program. You can know if a directory exists but using opendir(name) system call.
    For more, see the project page; it has been updated.
  • I'm having trouble figuring out how to remove the contents of a directory. I understand how unlink and rmdir works but I'm not quite sure how to remove my output directory
    • for this project, you can use the system() function call: system("rm -rf output/"); We changed our mind. It's dangerous to make a system() call with "rm -rf". Thus, we changed the project specification a little bit in terms of the output directory.

    Added 11/30:

  • The project specification says that directories will not consist of more than one data block. However, when checking the .i_blocks field of the directory inodes in the provided disk image, 3 of the directories have 2 blocks and 1 directory has 24 blocks.
    • if you find directory inodes that use more than one data block, just read the first data block, and ignore the rest. you should be able to find the jpg filenames in the first block.

    Added 11/26:

  • I am not able to find debugfs on one of the emperor machine. Any idea where I should look?
    • Yes it is. It's in /sbin/debugfs. Add this line to your .cshrc file:
    set path = ( $path /sbin )
  • Should we recover JPGs which do not exist in any directory entry (perhaps they have been deleted and the information about them in the parent directory overwritten, but the data blocks are intact)? Since we are already scanning every inode, this is possible, although it wouldn't be possible to recover the filename.
    • Yes. There are two parts of your project. The first one is to recover the jpg files and name them using the inode numbers (e.g. output/inode-xy.jpg. Thus, regardless whether you find the corresponding file names or not, you should recover these files). Second, you can always assume that the corresponding directory entries have not been reused such that all filenames are obtainable.

    Added 11/25:

  • Do we have to deal with deleted directories - I.E. will it be possible that a .jpg will be located in a directory that has been deleted. I was wondering, because if we don't have to deal with deleted directories, it seems like we can simply traverse the directory structure, and check the contents of each directory for .jpg files. If it's possible that we do have deleted directories, it seems like we need to iterate across every inode in the filesystem, and check the data of each inode to see if the file pointed to if a directory or a file, and handle each appropriately (which seems like it could get expensive).
    • Yes, it's possible. Thus, you should iterate all inodes (in fact, that's the purpose of this project). Iterating all inodes doesn't have to be slow. If you read all the inodes one block at a time, then it'll be slow. But since an inode table for each block group is always stored in contiguous blocks, you should read an inode table at a time.