CMPE2300 – Lab01 - Defrag-o-matic In this lab you will create a simulator to implement a file system defragmentation. Prior to SSDs, file systems benefited from ensuring files that were comprised of multiple disk partition units were allocated and adjacent on disk. This ensured minimum head movement for read/write of specific files. Our goal is to read in a text file formatted as one file allocation unit per row with a data component indicating the file name, a sequence number indicating part N ( of M ) units, and a next value indicating where the next unit resides. Once loaded and displayed the simulator will allow a basic defragmentation to be done, attempting to group files into adjacent allocation blocks. Program Specification Your project will require use of the CDrawer. You will need to define a structure to represent file allocation units, comprised of : • a string - representing the filename ( it will be one character for our simulation ) • an integer - representing the sequence number of this allocation unit • an integer - representing the allocation unit of the next part of the file. Assumptions : A next value of -1 indicates that this allocation unit is empty A next value of -2 indicates that this is the last allocation unit of this file Any file system load will always have > 0 empty units Your UI will have 3 buttons : [Load FileSystem] [Verify FileSystem] [Defragment] / Toggling to disable defragmentation And a listbox for status output – population should always use insert so newest additions are first. Part I - Load FileSystem Your application will be allowed to create class level members for the following : • List of File Allocation Units ( structure ) • CDrawer • integer representing CDrawer File Allocation Scale ( not CDrawer scale ) • constant integer representing the maximum width for the CDrawer in pixels = 1000 Bind your [Load FileSystem] click event to a method in your form constructor. [Load FileSystem] Dynamically create an OpenFileDialog, and using System.IO.Path.GetFullPath and the appropriate Environment variable, set the Initial directory to the root source ( this will allow easy loading of the test files in your project ). Using System.IO.File.ReadAllLines(), read the user selected file in. For each line read, you may use split() to separate the 3 expected elements to be processed. Process as required to make and add a structure entry to your List for each. Upon completion, add a status line in the form : “Load FileSystem: Loaded N units” Now that the load is complete, it needs to be displayed in the CDrawer. We want our displayed grid to be square – in number ( ie. 6 x 6 ). Given the load number, determine the smallest dimension that can be used. The “scale” is the file unit cell height, it will be 4 times wider than tall to fit our output requirements. Given the fixed CDrawer width, determine the “scale”, and close any existing CDrawer before allocating a new CDrawer of our calc.

1. CMPE2300 – Lab01 - Defrag-o-matic
In this lab you will create a simulator to implement a file
system defragmentation. Prior to
SSDs, file systems benefited from ensuring files that were
comprised of multiple disk
partition units were allocated and adjacent on disk. This ensured
minimum head
movement for read/write of specific files.
Our goal is to read in a text file formatted as one file allocation
unit per row with a data
component indicating the file name, a sequence number
indicating part N ( of M ) units,
and a next value indicating where the next unit resides. Once
loaded and displayed the
simulator will allow a basic defragmentation to be done,
attempting to group files into
adjacent allocation blocks.
Program Specification
Your project will require use of the CDrawer.
You will need to define a structure to represent file allocation
units, comprised of :
• a string - representing the filename ( it will be one character
for our simulation )
• an integer - representing the sequence number of this
allocation unit

2. • an integer - representing the allocation unit of the next part of
the file.
Assumptions :
A next value of -1 indicates that this allocation unit is empty
A next value of -2 indicates that this is the last allocation unit
of this file
Any file system load will always have > 0 empty units
Your UI will have 3 buttons :
[Load FileSystem]
[Verify FileSystem]
[Defragment] / Toggling to disable defragmentation
And a listbox for status output – population should always use
insert so newest additions
are first.
Part I - Load FileSystem
Your application will be allowed to create class level members
for the following :
• List of File Allocation Units ( structure )
• CDrawer
• integer representing CDrawer File Allocation Scale ( not
CDrawer scale )
• constant integer representing the maximum width for the
CDrawer in pixels = 1000
Bind your [Load FileSystem] click event to a method in your
form constructor.
[Load FileSystem]
Dynamically create an OpenFileDialog, and using
System.IO.Path.GetFullPath and the
appropriate Environment variable, set the Initial directory to the
root source ( this will allow

3. easy loading of the test files in your project ). Using
System.IO.File.ReadAllLines(), read the
user selected file in.
For each line read, you may use split() to separate the 3
expected elements to be
processed. Process as required to make and add a structure entry
to your List for each.
Upon completion, add a status line in the form : “Load
FileSystem: Loaded N units”
Now that the load is complete, it needs to be displayed in the
CDrawer. We want our
displayed grid to be square – in number ( ie. 6 x 6 ). Given the
load number, determine the
smallest dimension that can be used. The “scale” is the file unit
cell height, it will be 4
times wider than tall to fit our output requirements. Given the
fixed CDrawer width,
determine the “scale”, and close any existing CDrawer before
allocating a new CDrawer of
our calculated dimensions.
To actually display the file units, create a some new helper
methods :
MakeColors() – returns nothing and accepts nothing. It will be
invoked from the
constructor and will populate a form member List<Color> with
a new list then fill the list
with colors derived from r, g and b values of 64, 128, 192 (
notice the pattern – a triple
nested loop is required ). The list will now be comprised of ??
colors, matching our

4. alphabet filename needs.
RenderUnits() – returns nothing, accepting a List of file units, a
CDrawer and the file unit
height. Clear() the CDrawer, and iterate through all the file
units. For each, construct a
Rectangle object with the appropriate X, Y coordinates ( Grid
work ? ), a width 4 times the
height. If the file unit is empty, fill the rectangle with gray.
Otherwise, use the letter as the
offset ( ie. a is 0, b is 1,.. z = 25 ) fill the rectangle with the
indexed color from our colors list.
Then using the same Rectangle, use AddText to populate the
rectangle with file unit's
information in the form :
file_name:sequence_number:next_value, ie. h:3:34
Remember to render your CDrawer.
Now include RenderUnits as the last thing in your load function
to see your filesystem.
Part II – Verify File System
Just because our file system loaded it does not mean it is valid.
We need to validate the
loaded system to ensure all file units ( and supposed empty
space ) are error free. This
step is of your own design, with these basic requirements :
• Every file unit will start having a sequence number of 0. A file
unit chain must end
with a next value of -2. A file may consist of a single file unit (
sequence = 0 and next
of -2 ).
• Verification requires that every file unit chain is in sequence

5. and terminates
correctly.
• Verification may discontinue on the first error found – as
many possible errors could
potentially create an avalanche of cascading and compounding
errors.
• Any error found should result in a status addition in the
following form :
Validation:Error:error_condition with appropriate values.
Error conditions would include, but not be limited to :
• File_name : termination missing
• File_name : out of sequence
• File_name : start unit missing
Your instructor will discuss possible approaches.
Part III – Defragmentation
We need some helper functions to implement defragmentation.
FirstEmpty() - returns an integer representing the found empty
index, accepts a list of file
units and a bool representing if the search should start halfway
through the list – set a
default value of false. This method is used to find an available
spot to move an existing file
unit for defragmentation. Depending on the bool flag, start
searching the list returning the
index of the first empty spot encountered in the supplied list.
Starting halfway must still
cycle around through to the start looking for an empty spot.

6. Only a single loop and
remembering our assumptions is required.
MoveUnit() - returns void, accepts a list of file units, a list
index to move and a list index to
move the file unit to. In order to move a file unit, there may be
an existing file unit that has
a next value referencing the move location. This unit must be
modified in order to maintain
order in the move. Therefore, using the file name and move
index determine ( if any ) prior
unit exists – save this index ( or -1 for no prior unit found ).
Now perform the move – the order is critical here – copy the
unit to be moved to the new
empty location, modify ( if required ) the prior unit, lastly set
the move index unit to empty.
Why is this important if this were real defragmentation ?
NeedDefrag() - returns an index indicating a unit that should be
defragged. It accepts a
list of file units. We will use a “lazy” evaluation of whether
defragmentation is required. It
involves 2 distinct passes through the list.
The first pass determines if we have a “starter” unit ( seq = ? )
and if the next unit is not next
in line. If so, we want this unit defragged, return this index.
The second pass, if the first pass found nothing, determine if a
unit is found where the next
unit is not the next in line. If so, we want to this unit defragged,
return the index.
This method is biased to try to defragment units which are the
start of a file unit chain.
Thread method Defrag(), accepts an object ( the list of units to
defragment ) and returns
nothing. This method will be used as a Thread target, created

7. and started when the user
clicks the Defragmentation button. The thread reference should
be created as a form
member and will be used by the thread to monitor for
termination.
Repeat forever while the thread reference is valid :
Render your file system, have short sleep ( 25ms for checkoff,
500ms or more for debug )
Invoke your NeedDefrag() method saving the returned unit
index. If no units need debug
break your loop, set your thread reference to null and let the
method complete.
Otherwise we have a unit whose next adjacent unit is wrong.
There is a special case here,
if the last unit is indicated, we can't move ANY adjacent units.
So, if the unit indicated is the
last node and is not the last node in the file chain, invoke
MoveUnit with the unit index and
the index returned by FirstEmpty() retrieving the true first
empty index. If this special case
occurred, this pass is complete, continue.
Normal processing is to determine the swap index for our move
of the adjacent next unit
that is out of place. Invoke FirstEmpty() with a midway start
saving the returned index as
our swap index. Now we have a unit to move and a place to
move it to, but we are moving
the next unit to make room for the unit that belongs there !
MoveUnit() the adjacent unit to our swap index, ie. move it out

8. of the way.
MoveUnit() the unit that belongs next, to the next index spot. (
use next value )
The cycle is complete, one down, many to go. Prior to exiting
your thread method, ensure
you set the thread member to null, indicating the thread is
complete.
You will need to update the main UI as to the progress made by
Defrag(). Determine an
appropriate delegate type, and using Invoke() ( not
Dispatcher.Invoke() ), invoke a string
message back to the main UI thread to update the status listbox
for each MoveUnit
operation in the form “Defrag: Moved [N] to [M]”.
To finish wiring up the UI, implement a toggle action on the
button so it toggles between
[Defragment] and [Cancel Defrag], using the thread member as
both the indicator for the
button text and the flag for your thread termination. Your thread
should Invoke a message
back prior to exiting in the form “Defrag:Thread terminated”
Mark completion rubric.
Part I : Basic UI, Load and Render to spec 30
Part II : Verify filesystem, functional, correctly identifies test
files 30
Part III : Defragmentation, functional for supplied test files 40
Tips

9. Do not code more than a few lines before testing / debugging.
Do ask questions about functionality, operation, assumptions on
your part.
CMPE2300 – Lab01 - Defrag-o-maticProgram SpecificationTips