A Portable File System
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 system.
When your program is running it should somehow accept the following commands:
open PFS file Allocate a new 10 K Byte "PFS" file if it does not
already exist. If it does exist, begin using it for further
put my file Copy the Windows file "my file" into your PFS file.
get my file Extract file "my file" from your PFS file and copy it to
the current Windows directory.
R m my file Delete "my file" from your PFS file.
dir List the files in your PFS file.
Put r my file "Remarks" Append remarks to the directory entry for my file in
your PFS file.
kill PFS file Delete the PFS file from the Windows file system.
quit Exit PFS.
You 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.
other words, it may pay you to do this project early on the off chance that something prohibits your submitting it in a timely
way. If your program is not working by the deadline, submit it anyway and review it together with GA for partial credit. Do not take a zero on any lab just because the program isn’t working yet. If you have trouble getting started, ask the professor or the GA.