Project 2 – A Portable File System
Due: Tuesday, December 2, 2014. 11:59:59 PM (EST)
1. Practical experience with the problems of file systems.
2. Experience with the Windows NT operating system.
3. Keep the definition simple. Don't read things into the problem that aren't there. These will be individual projects. For Project 2 you will use Windows 7 or 8. (If you are working away from the University you may be able to develop this program on Windows
7 or 8 but you will have to demo it on Windows 7.) You may write the program in any language that is supported under any Integrated Development Environment (IDE) that runs on Windows 7. Keep in mind that more help may be available to you in some languages than in others. Furthermore, available controls, etc. may make some of these tasks easier in one language than in another.
Implement a Portable File System (PFS). Allocate a file. Move files from the Windows file system into your file. You should have your own directory structure, allocation table, etc. inside your file. Move files back out of your file to the Windows file [url removed, login to view] your program is running it should somehow accept the following commands:open PFSfile Allocate a new 10 KByte "PFS" file if it does not already exist. If it does exist, begin using it for further commands.
put myfile Copy the Windows file "myfile" into your PFS file.
get myfile Extract file "myfile" from your PFS file and copy it to
the current Windows directory.
rm myfile Delete "myfile" from your PFS file.
dir List the files in your PFS file.
putr myfile "Remarks" Append remarks to the directory entry for myfile in
your PFS file.
kill PFSfile Delete the PFSfile from the Windows file system.
quit Exit [url removed, login to view] can provide those commands either through menus or through buttons on a
form (or both). If the user clicks a button in your application window, it might open up a
dialog box to get a filename. Alternatively, you can just open up a text box and let the
user key in the name of a file (or whatever other variable information you need.)
Filenames are a max. of 20 bytes. The directory need handle only Name, Size, Time and
Date. If the original PFS file fills up then you should create a new PFS "volume" with the
same name but a different suffix - e.g., pfs.1, pfs.2, etc., each the same size as the first
"volume". Your file system should use an allocation scheme where "disk blocks" are 256
bytes each. You should handle unusual conditions such as trying to put a file into the PFS
when a file with that name is already there, file too large to fit into one "volume", etc.
If you need to make assumptions, do so. Make a “reasonable” choice & include it in the
write-up. Reasonable means that you can explain the logic behind your choice. These
problems change each semester and it is difficult to imagine every question that might
come up. When in doubt, ask the Lecturer or the GA.
You should submit a write-up as well as your program. Your write-up should include any
known bugs, limitations, and assumptions in your program. This write-up should be in
text-format and titled as ‘README’. It should be submitted along with your code. GA
will use the ‘README’ file to compile (or install) and run your program. If the GA has
trouble with your program then he will contact you to makeup it.
Any Language can be used that can be run on the Windows system.
10 Allocate new PFS file
10 Copy file into PFS
10 Extract file from PFS
10 Handle second PFS Extent when full
10 Kill PFS file
10 Delete file from PFS
10 Add remarks to a file
10 DIRectory listing
10 Error conditions
05 Comments in code
10 Encrypt the PFS
10 Associate a program with a PFS file & launch it
putc myfile runcommand Associate a program to be run against this file.
run myfile Extract "myfile" from the PFS and run it with the associated command.