Operating Systems 2019W: Assignment 2: Difference between revisions
No edit summary |
|||
Line 1: | Line 1: | ||
Please submit the answers to the following questions via CULearn by 4 PM on Monday, February 11, 2019. There are 20 points in 9 questions (and 4 points extra credit). | Please submit the answers to the following questions via CULearn by 4 PM on Monday, February 11, 2019. There are 20 points in 9 questions (and 4 points extra credit). | ||
Revision as of 18:54, 1 February 2019
Please submit the answers to the following questions via CULearn by 4 PM on Monday, February 11, 2019. There are 20 points in 9 questions (and 4 points extra credit).
Submit your answers as a single text file named "<username>-comp3000-assign2.txt" (where username is your MyCarletonOne username). The first four lines of this file should be "COMP 3000 Assignment 2", your name, student number, and the date of submission. You may wish to format your answers in Markdown to improve their appearance.
No other formats will be accepted. Submitting in another format will likely result in your assignment not being graded and you receiving no marks for this assignment. In particular do not submit an MS Word or OpenOffice file as your answers document!
Don't forget to include what outside resources you used to complete each of your answers, including other students, man pages, and web resources. You do not need to list help from the instructor, TA, or information found in the textbook.
Questions
- [2] Assume you have a file A. You type ln A B in order to create file B. If you delete A, what happens when you try to read B? Why?
- [2] Assume you have a file A. You type ln -s A B in order to create file B. If you delete A, what happens when you try to read B? Why?
- [2] What does fsck do if it finds an allocated inode that no file refers to? How could this problem arise?
- [2] Describe a situation where a UNIX sparse file could cause problems for a backup program (that didn't specially treat sparse files).
- [2] Is a filesystem's superblock accessed frequently in normal operation? Why or why not?
- [2] When first connecting to a remote host via ssh, you will normally get a message saying something similar to this: "The authenticity of host 'access.scs.carleton.ca (134.117.29.72)' can't be established. RSA key fingerprint is SHA256:MexEKZF0Os0Vl6VTObN70lRf2DFsGfD8DTQ7FKKqVJ4. Are you sure you want to continue connecting (yes/no)?"
- Is it normally safe to say yes to this question? Why?
- Describe a situation when you should say no. Give a specific example of a "bad thing" that could be happening.
- [3] Modify 3000test.c so it can report on what access the current user has to the file. Give your code as a "diff -c" relative to the original 3000test.c.
- [3] Create a program 3000run-write.c (based on 3000test.c) that attempts to run the contents of a (specific) file by mmap'ing it into an array, converting the array pointer into a function pointer, and then calling the function. The called function should have the same declaration as write(), and you should call it with three arguments: 1, "Hello there!\n", and 13. When your program is given the file write.bin as a command-line argument, it should print out "Hello there!" to standard out (the terminal). Give the code of 3000run-write as a "diff -c" versus the original 3000test.c.
- [2] You run the commands below, replacing <scs-username> with your SCS username. After running these commands (and assuming the sshfs command succeeds), how many copies of "test.txt" exist? Where are they stored?
echo "This is random text" > test.txt mkdir scs-files cp test.txt scs-files sshfs <scs-username>@access.scs.carleton.ca:. scs-files <login to access.scs.carleton.ca> mkdir scs-files/testdir cp test.txt scs-files/testdir rm -f scs-files/test.txt fusermount -u scs-files rm -f scs-files/testdir/test.txt
EXTRA CREDIT (4 points): Make a file write-upper.bin that, when loaded by 3000run-write, writes out the upper case version of the string given as the second argument. You may modify the passed in string.