XML CO527 Anonymous Questions and Answers Keyword Index

This page provides a keyword index to questions and answers. Clicking on a keyword will take you to a page containing all questions and answers for that keyword, grouped by year.

To submit a question, use the anonymous questions page. You may find the keyword index and/or top-level index useful for locating past questions and answers.

Keyword reference for assess5-1516

Question 84 (2015):

Submission reference: IN5134

Hi I'm trying to find all blocks of file BAR for question 8 but I keep hitting blocks with just zeros. Can you tell me where I'm going wrong please? This is my calculation so far:

[... some calculations ...]

Answer 84:

I'm sorry, but I don't understand at all what you are trying to do. Perhaps the recent answer to Question 83 (2015) will be helpful?

Keywords: assess5-1516

Question 83 (2015):

Submission reference: IN5133

This is my attempt on question 8 which I would like feedback on the explanation to see if I am right or wrong on my calculations.

[... An attempt at Q8. Snippets are quoted in the answer....]

Answer 83:

What we know : start of cluster 000a -> 0x10

What does this mean? '000a' looks like it might be a a hex number because of the 'a', although there's no clear '0x' to indicate so. The number 0x10 is clearly in hex, because it's marked by 0x. So, rewriting "000a -> 0x10" in the more familiar decimal notation we get "10 -> 16". What does it mean?

Well, … obviously, I can guess what it means. You meant to convert the hex number 0xa to the decimal number 10. But the way you write numbers is very confusing, and you will get confused if you don't keep the separation hex/decimal straight.

so 0x10+0x2B = 0x0035

Really? I thought 0x10+0x2b = 0x3b, because 0x0+0xb is 0xb, no carry; and 0x1+0x2=0x3, again no carry. Notice how I'm using the normal addition algorithm, going digit by digit from right to left.

But, again, I guess you actually mean 10 instead of 0x10. So the operation is 10+0x2b. I don't know how to compute that because it mixes bases, so I'll convert to the same basis. (a) Let's try decimal: 10 + 2*16 + 11 = 21 + 32 = 53. (b) Just for fun, let's double check if we get the same answer in hexadecimal (we should!): 0xa + 0x2b = 0x35. How do I know that? Well, 0xa+0xb=0x15, so 5 with a carry of 1; and 0x2+0x1=0x3. (How do I know that 0xa=0xb=0x15 you ask? The same way I know addition between single digit numbers in decimal: I count on my fingers. Or I remember it. But, in this case, I used fingers.) Is 0x35 the same as 53? Let's see 3 * 16 + 5 = 48 + 5 = 53. Yes.

If I ignore the very confusing mixup in notation between decimal and hexadecimal, there is no mistake so far.

000a in binary form to attempt the 12 bit conversion

No. You don't need to convert 0x000a to anything. You just need to find the 11th group of 12 bits in the FAT table. (11th, because it's at index 0xa=10, and we start indices from 0, as usual; See also Question 74 (2015))

Here this is a bit tricky because of endianness. So, let's say, hypothetically, that the content of the FAT table is the following:

0x00 0x01 0x02 0x03 0x04 0x05

The way to think about this is that bits are in little endian order:

00000000 10000000 01000000 11000000 00100000 10100000

Now we regroup these in groups of 12 bits:

000000001000 000001000000 110000000010 000010100000

And now we read them as numbers, using the same endianness convention (which means we swap left-and-right again): 0b000100000000, 0b000000100000, 0b010000000011, 0b000001010000. And, back to hex: 0x100, 0x020, 0x403, 0x050. So, for example, the third entry in this FAT12 table is 0x403.

If you look carefully at all the left-right bit-flipping above, you'll see that groups of four bits never get split, and you get the algorithm from this page, which I already mentioned in Question 74 (2015). (And it is the algorithm you tried to apply to 0xa, which is incorrect.)

Two questions: 1) Is my working correct?

The first serious mistake is that you try to shuffle the bits of 0xa, which you shouldn't, as I said above. But the computations that come before, although ending up with correct answers, are not properly saying in which base you are working.

2) the hexadecimal values i found must be converted to 12 bit as well right, since they are FAT entries?

You don't need to find a 16bit value and then convert it to a 12bit value (whatever you may mean by "convert" …). FAT entries have 12 bits; you just need to find the 11th FAT entry (and then repeat, as explained in Question 74 (2015)).

Keywords: assess5-1516

Referrers: Question 84 (2015)

Question 80 (2015):

Submission reference: IN5130

I'm stuck on Q3.

[... some wrong arithmetic ... ]

Can you please advise me where I have gone wrong?

Answer 80:

See Question 78 (2015) and Question 72 (2015).

Some details:

1. Numbers are not the same as their representations. For example, these all represent the same number: 14+12, 26, 0x1a, 0x7+0x13, 2*(15-2), XXVI.
2. In the positional number system, the algorithms for getting rid of operations like + and * are simple. (Or, at least, simpler than they are with, say, roman numerals.) These algorithms work for any base, but you are likely to have experience applying them in base 10. These algorithms do not work if you mix one base with another. So, you should always be clear about which representation you use, so you don't mix them.
3. Luckily, there are simple algorithms for converting from one base to another.
4. Even more luckily, you don't need to do any arithmetic yourself: there are plenty of calculators to do it for you. You can even type it into google.

Keywords: assess5-1516

Question 79 (2015):

Submission reference: IN5129

For question 8 of the FAT assignment, do we need to order the blocks in how they are found or order them based on the block number i.e. if u found block 200 first in the FAT then the next cluster takes u to 180, would u write it down as block 200,block 180 or block 180,block 200.

Thank you very much!

Answer 79:

200, 180

Keywords: assess5-1516

Question 78 (2015):

Submission reference: IN5128

If the way of working out where a root directory appears is by doing

(size of FAT)*(number of FATs) + 1

[... some wrong multiplications ...]

Answer 78:

You need to be able to do multiplications correctly for this assignment. Stay with decimal numbers if that's what you feel more comfortable with. You can also do multiplications using a calculator. For example:

rg@rg-2016:temp$ python3
>>> 0x08 * 2
16
>>> hex(16)
'0x10'

See also Question 72 (2015).

Keywords: assess5-1516

Referrers: Question 80 (2015)

Question 77 (2015):

Submission reference: IN5123

Here is my solution to question 8, I followed the tutorial given but keep on ending up at a blank block!

[...]

Max. number of entries in root directory: 0x0002 =-> 2 entries.

[...]

Answer 77:

One problem is that the maximum number of entries in the root directory is not 2. This should be obvious, since question 3 asks about the 5th entry. Two is less than five, so alarm bells should ring.

Your solution has many other mistakes. Some of these mistakes are irrelevant to question 8 (for example, the file size is wrong), and some of these mistakes come after the mistake I called out above. In any case, you need to slow down, and go through the tutorial carefully.

Keywords: assess5-1516

Question 76 (2015):

Submission reference: IN5121

I've been reading Bob's guide in how to find the next cluster of a file in however it is not getting me anywhere. Here is my working out, please could you point me in the right direction.

[...]

Answer 76:

See Question 74 (2015)

Keywords: assess5-1516

Question 75 (2015):

Submission reference: IN5120

For question 4 about the date of creation for VIMRC, i'm having trouble understanding Bob's explanation of how to interpret the date. I'm not quite sure how the one value at 0x18/0x19 can be converted or read to retrieve a date.

Answer 75:

You need to write down all 16 bits. The most significant 7 bits indicate the year, the next 4 bits indicate the month, and the least significant 5 bits indicate the day.

Keywords: assess5-1516

Question 74 (2015):

Submission reference: IN5119

I'm on question 8 and following the tutorial and I keep getting sent to an empty block. Could you please tell me where I am going wrong. [... description of an attempt to solve question 8 ...]

Answer 74:

You hit the one relevant difference between FAT16 and FAT12.

Given cluster x, FAT[x] gives the number of the cluster coming after x. So, if a file starts at cluster x, then its clusters are x, FAT[x], FAT[FAT[x]], ..., and so on until a special value indicating the end is hit (-1 in two's complement).

For the above paragraph to make sense, you need to see FAT as an array. For that, you need to know where it starts (which you did), and you need to know how big are its elements (how many bits they occupy). For FAT16, an element takes two bytes (which is why you start with multiplying x by 2); For FAT12, it takes 12 bits, so you don't multiply x by 2. Instead search for "Since 12 bits is not an integral number of bytes" on this page, and use that description.

(In your description, there's also a minor misunderstanding of why Bob divides 2x by the size of a block: the point is to figure out in which block to look and where, so you care about quotient and reminder, not about a real value.)

Keywords: assess5-1516

Referrers: Question 76 (2015) , Question 83 (2015) , Question 83 (2015) , Question 83 (2015)

Question 73 (2015):

Submission reference: IN5117

Am I right in thinking that we should be following "The Starting Cluster Number" section on the preliminaries to find the number contained in the file 'SECRET'? Thank you

Answer 73:

Yes. See also section 'Example 4 - find the data blocks for a file' of the tutorial.

Keywords: assess5-1516

Question 72 (2015):

Submission reference: IN5115

I have followed the tutorial to do question 3 but it does not seem right. [Removed an attempt at solving question 3. It includes something like 0x09 * 2 == 0x18, which is incorrect.]

Answer 72:

Your arithmetic is incorrect. You may want to convert all numbers to decimal before doing any additions/multiplications, to avoid mistakes.

For example, instead of (0x09 * 2 == 0x12), you may want to work with (9 * 2 == 18), which is a form you may be more familiar with.

Keywords: assess5-1516

Referrers: Question 78 (2015) , Question 80 (2015)

Question 71 (2015):

Submission reference: IN5114

Is XXXX blocks the right answer for question 1 or have I gone in the wrong direction about the whole thing?

Answer 71:

At this point, I can't comment on what the right answer is.

Keywords: assess5-1516

Question 70 (2015):

Submission reference: IN5113

In the brief explanations do I need to talk about some of the calculations I have used or is that going too much in to detail?

Answer 70:

It is up to you to decide what is important and what is not important in how you found an answer. A calculation may or may not be important.

Keywords: assess5-1516

Question 69 (2015):

Submission reference: IN5112

Could you please tell me if my methodology is right for converting from FAT16 to FAT12 If the 16 bit number is 0x0013 (19 in decimal) divide it by 1.5 to make it the 12 bit number 0x000d (12.66 and then round it up to 13 in decimal) and then go to that block to find the correct directory. Thank you

Answer 69:

Would you just follow the tutorial? You don't need to convert any numbers. (But see Question 68 (2015).)

FAT is a file system format, not a number format. So, "to convert a number from FAT16 to FAT12 you divide by 1.5" is not right or wrong: it is an ill-formed sentence.

Keywords: assess5-1516

Question 68 (2015):

Submission reference: IN5111

So in Bob Eager's tutorial he uses FAT16 where as we are using FAT12. When working out the root directory or working out how many blocks are there, it does not make a difference so I am not sure at what point does it make a difference whether it is a FAT16 OR FAT12

Answer 68:

A FAT entry takes 12 bits on FAT 12, not 16 bits. So, when you read in the tutorial that a FAT entry takes 16 bits (two bytes), replace that by 12 bits.

Keywords: assess5-1516

Referrers: Question 69 (2015)

Question 67 (2015):

Submission reference: IN5110

How detailed should our brief descriptions for assessment 5 be?

Answer 67:

Quite brief.

Keywords: assess5-1516

Question 66 (2015):

Submission reference: IN5109

For assessment 5 are meant to just extract the file dump and view it in notepad? It looks like a mess, just want to make sure i'm viewing it properly.

Answer 66:

The file dump.txt should contain a hex dump that looks like the examples in Bob's tutorial: example.

You may want to use a better text editor than Notepad, though.

Keywords: assess5-1516

Question 64 (2015):

Submission reference: IN5066

I just had a quick question about the file system assignment, I know that the tavi webpage provided goes through FAT16 file system, I was wondering are we meant to go by the tables that are provided in the tavi for the FAT16 or look at the documentation for FAT12 as they have different lookup values for certain aspects e.g. the FAT16 for date create is located at 0x18 but in the FAT12 documentation it is located at 0x10

Answer 64:

The file system in dump.txt is FAT12, as mentioned in the assignment and as you can see in Block 0. Hence, you should of course use the format specs for FAT12 to interpret its content.

That said, the only difference in the formats FAT12 and FAT16 that you care about is the one mentioned in the assignment: FAT entries take 12 bits in FAT12, and 16 bits in FAT16.

In particular, the date is at indices 0x18 and 0x19 in both FAT12 and FAT16. Either the documentation you use for FAT12 is rubbish, or you are not reading it properly. Here's another place were all FAT versions are documented: The FAT filesystem.

Keywords: assess5-1516

Question 63 (2015):

Submission reference: IN5063

When will the file systems assignment be released?

Answer 63:

It is released now. See Moodle.

Keywords: assess5-1516