[rloew]

dencorso, on 27 November 2011 - 09:09 PM, said:

I never meant to say there were any problems from the POV of the standard. The "Number of Directory Entries" is two bytes, of course, so (if unsigned) 65,525 entries are allowed for. I just wished to point out that MS says there can be compatibility problems (most probably just with deprecated versions of some MS applications) when more than 512 entries are used. Then, I went ahead and typoed, and you cached my typo, as usual. And I was so certain of what I thought I had written, that only at this moment it dawned on me I had written "255" instead of "512". I'm sorry, I really do try to be as clear as best as I can, but more than once my typos conspire against me (and, BTW, that's why works meant for publication must have someone other than the authors revising them before going to press, although, nowadays, it doesn't always happen anymore). Thanks for the heads up! You rock!

Actually they don't say there is a problem having more than 512 Entries, at least in this particular Article. They just assume that only 512 Entries are allocated, which obviously limits the number of files. I would not be surprised if many applications exist that would choke on more than 512 since all standard Formatters set 512 or less. It might be interesting to determine the absolute limit. it is easy for me to setup any limit I choose.

You are not the only one who has reviewed his writing multiple times and missed the same typo every time. I have done it too. As more and more Authors self-publish, there is going to be less and less review.

EDIT: The absolute limit appears to be 4096 Root Directory Entries. I have seen evidence that the Sector Offset into the Root Directory is limited to a Byte.

This post has been edited by rloew: 28 November 2011 - 02:22 AM

[jaclaz]

OT , but just to keep things together as possible, the opposites of superfloppies (would they be "underfloppies"? )
http://reboot.pro/8752/page__st__59
(I just happened to get by chance on that thread again, that I had completely forgotten)

jaclaz

This post has been edited by jaclaz: 30 November 2011 - 03:16 AM

[dencorso]

Not underfloppies, no.
Subfloppies, of course!
But... that'd mean something with a total space less than 160 KB...

[jaclaz]

dencorso, on 30 November 2011 - 08:46 AM, said:

But... that'd mean something with a total space less than 160 KB...

Exactlly, the "smallest" subfloppy (but with "large" capacity) I managed to produce has only 2560 bytes free, but is pretty FAST in loading to --mem with grub4dos....
4096 bytes total size, gzips in 246 bytes.
I might review it at the light of the new findings on this thread an maybe I can find a way to make it even smaller.

jaclaz

This post has been edited by jaclaz: 30 November 2011 - 10:19 AM

[jaclaz]

Hey, kids, noone wanting to play with me anymore?

I am almost finished with the spreadsheet , but I just got a doubt.

The three bytes jump code is actually part of the CODE and NOT of the BPB, right?

I mean, if I want to make a non-bootable bootsector those three bytes should be 00 00 00, and ONLY when I decide to apply the bootsector CODE, then they will get (examples):
EB 3C 90 (MS)
EB 3C 90 (FREEdos)
EB 58 90 (some other bootsectors)
etc.

Or do you think that by default (if NO code is chosen) I should put a non-bootable bootsector code?

Same question goes for the "Magic Bytes" 55 AA:
http://linuxgazette....e84/dashti.html
are they used only if the bootsector is bootable (thus CODE) or they define the sector as a bootsector (and thus they should also be 00 00 by default)?

Suggestions for a Public Domain or however freely redistributable bootsector code that can print a message (or display an image) welcome.


JFYI, I have also started working on a few batches, and then stopped and then started again....., and again, and again....
....I will do such things, ....
....What they are, yet I know not: but they shall be
The terrors of the bootsectors


jaclaz

[rloew]

jaclaz, on 11 January 2012 - 10:38 AM, said:

Hey, kids, noone wanting to play with me anymore?

I am almost finished with the spreadsheet , but I just got a doubt.

The three bytes jump code is actually part of the CODE and NOT of the BPB, right?

I mean, if I want to make a non-bootable bootsector those three bytes should be 00 00 00, and ONLY when I decide to apply the bootsector CODE, then they will get (examples):
EB 3C 90 (MS)
EB 3C 90 (FREEdos)
EB 58 90 (some other bootsectors)
etc.

Or do you think that by default (if NO code is chosen) I should put a non-bootable bootsector code?

Same question goes for the "Magic Bytes" 55 AA:
http://linuxgazette....e84/dashti.html
are they used only if the bootsector is bootable (thus CODE) or they define the sector as a bootsector (and thus they should also be 00 00 by default)?

Suggestions for a Public Domain or however freely redistributable bootsector code that can print a message (or display an image) welcome.


JFYI, I have also started working on a few batches, and then stopped and then started again....., and again, and again....
....I will do such things, ....
....What they are, yet I know not: but they shall be
The terrors of the bootsectors


jaclaz

The first three bytes are required. FileSystems do check it, even if not bootable. It does not need to point to actual code if it can never be booted.
It must be:

JMP SHORT
NOP

or

JMP LONG

The Magic Bytes are required regardless of Bootability. The BPB will not be read if the Magic Bytes are missing.

Making a Boot Sector that only Prints a message if Booted is a trivial exercise in Assembly Code, use Interrupt 10H.

This post has been edited by rloew: 11 January 2012 - 01:56 PM

[jaclaz]

rloew, on 11 January 2012 - 01:53 PM, said:

The first three bytes are required. FileSystems do check it, even if not bootable. It does not need to point to actual code if it can never be booted.
It must be:

JMP SHORT
NOP

or

JMP LONG

The Magic Bytes are required regardless of Bootability. The BPB will not be read if the Magic Bytes are missing.

Making a Boot Sector that only Prints a message if Booted is a trivial exercise in Assembly Code, use Interrupt 10H.

You make it sound a little bit too obvious and B/W for my tastes.

There is a whole lot of shades of grey. http://reboot.pro/15878/

Experiments:

• make a "normal" floppy disk image with *any* bootsector starting with EB3C90 and ending with 55AA, write to it a simple .txt file.
  
• remove from it any boot code (optional).
  
• Replace 55AA with 00.
  
  • Image can be mounted by IMDISK (and it's filesystem is recognized and it's contents are listed).
    
  • Same can be done in a Qemu VM booting a DOS 7.1 floppy and putting the image as second floppy.
  
  
• Replace EB3C90 with EB3C00.
  
  • Image can be mounted by IMDISK (and it's filesystem is recognized and it's contents are listed).
    
  • When in the VM, it fails with "General failure reading drive M" with DOS7.1, AND it cannnot be accessed properly by FREEdos
  
  
• Replace EB3C00 with EB5800.
  
  • Image can be mounted by IMDISK (and it's filesystem is recognized and it's contents are listed).
    
  • When in the VM, it fails with "General failure reading drive M" with DOS7.1, BUT it can be accessed allright by FREEdos, BUT ONLY if before you access another floppy
  
  
  
• Replace EB5800 with EB0000.
  
  • Image can be mounted by IMDISK (and it's filesystem is recognized and it's contents are listed).
    
  • When in the VM, it fails with "General failure reading drive M" with DOS7.1, BUT it can be accessed allright by FREEdos, BUT ONLY if before you access another floppy
  
  
  
• Replace EB0000 with 000000.
  
  • Image CANNOT be mounted by IMDISK.
    
  • When in the VM, it fails with "General failure reading drive M" with DOS7.1, BUT it can be accessed allright by FREEdos, BUT ONLY if before you access another floppy
  
  
• Replace EB0000 000000 with EB0090.
  
  • Image can be mounted by IMDISK (and it's filesystem is recognized and it's contents are listed).
    
  • Same can be done in a Qemu VM booting a DOS 7.1 floppy and putting the image as second floppy, AND it can be accessed allright by FREEdos, BUT ONLY if before you access another floppy
  
  
• Replace EB0090 with EB0190.
  
  • Image can be mounted by IMDISK (and it's filesystem is recognized and it's contents are listed).
    
  • Same can be done in a Qemu VM booting a DOS 7.1 floppy and putting the image as second floppy, AND it can be accessed allright by FREEdos, BUT ONLY if before you access another floppy
  
  
• Replace EB0190 with 000000 AND re-add the Magic Bytes 55AA.
  
  • Image CANNOT be mounted by IMDISK.
    
  • When in the VM, it fails with "General failure reading drive M" with DOS7.1, BUT it can be accessed allright by FREEdos
  
  
  
• Replace 000000 with E90000.
  
  • Image can be mounted by IMDISK (and it's filesystem is recognized and it's contents are listed).
    
  • Same can be done in a Qemu VM booting a DOS 7.1 floppy and putting the image as second floppy, AND it can be accessed allright by FREEdos
  
  
• Leave the three bytes E90000 but remove the Magicbytes.
  
  • Image can be mounted by IMDISK (and it's filesystem is recognized and it's contents are listed).
    
  • Same can be done in a Qemu VM booting a DOS 7.1 floppy and putting the image as second floppy, AND it can be accessed allright by FREEdos, BUT ONLY if before you access another floppy

I am attaching a set of such 1440K floppy images.

Preliminary conclusions .

• under both DOS and XP the Magic Bytes are ignored and have NO influence whatsoever with reading/accessing the BPB, so they are part of the CODE (and not of the BPB) .
  
• XP only checks if first byte is EB OR that first byte is E9 (the three one jump bytes are is part of the BPB)
  
• DOS 7.1 checks that first byte is EB and third is 90 (the three two jump bytes are part of the BPB) OR that first byte is E9 (the three one jump bytes are is part of the BPB)
  
• FREEdos ignores the three jump bytes and only checks for Magic Bytes (so , Magic Bytes is part of the BPB and NOT of the CODE, and the three jump bytes are part of the CODE and NOT of the BPB ) and it also has some kind of "sticky attitude" if it accesses another properly setup floppy, somehow the Magic Bytes are "ported over".

jaclaz

Attached File(s)

•  EBE955AA.zip (3.32K)
  Number of downloads: 4

[rloew]

jaclaz, on 12 January 2012 - 09:06 AM, said:

rloew, on 11 January 2012 - 01:53 PM, said:

The first three bytes are required. FileSystems do check it, even if not bootable. It does not need to point to actual code if it can never be booted.
It must be:

JMP SHORT
NOP

or

JMP LONG

The Magic Bytes are required regardless of Bootability. The BPB will not be read if the Magic Bytes are missing.

Making a Boot Sector that only Prints a message if Booted is a trivial exercise in Assembly Code, use Interrupt 10H.

You make it sound a little bit too obvious and B/W for my tastes.

There is a whole lot of shades of grey. http://reboot.pro/15878/

They are required if you want general compatability. I never said you couldn't scrounge up something that could read them.

Quote

Preliminary conclusions .

• under both DOS and XP the Magic Bytes are ignored and have NO influence whatsoever with reading/accessing the BPB, so they are part of the CODE (and not of the BPB) .
  
• XP only checks if first byte is EB OR that first byte is E9 (the three one jump bytes are is part of the BPB)
  
• DOS 7.1 checks that first byte is EB and third is 90 (the three two jump bytes are part of the BPB) OR that first byte is E9 (the three one jump bytes are is part of the BPB)
  
• FREEdos ignores the three jump bytes and only checks for Magic Bytes (so , Magic Bytes is part of the BPB and NOT of the CODE, and the three jump bytes are part of the CODE and NOT of the BPB ) and it also has some kind of "sticky attitude" if it accesses another properly setup floppy, somehow the Magic Bytes are "ported over".

No Windows 9x tests?

The BPB is the block starting at Offset 0xB only. The Jump Bytes are part of the Code and FAT Validation. The Magic Bytes are for Boot Sector Validation only.
In a non-Bootable Partition or disk, the Jump Destination does not matter.

[jaclaz]

rloew, on 12 January 2012 - 12:16 PM, said:

No Windows 9x tests?

No, I thought that DOS 7.1 would have done for the moment.

rloew, on 12 January 2012 - 12:16 PM, said:

The BPB is the block starting at Offset 0xB only.

And what about this?
http://homepage.ntlw...name-field.html

Where does the actual BPB end?
Theoretically at 0x24

It seems like we have to consider the existence of a "real" BPB AND of an eBPB (extended Boot Parameter Block)
http://support.micro...kb/140418/en-us
(and consequently "divide" the set in BPB and eBPB)

rloew, on 12 January 2012 - 12:16 PM, said:

The Jump Bytes are part of the Code and FAT Validation.
In a non-Bootable Partition or disk, the Jump Destination does not matter.

Yep , but as seen we need to have at least EB0090 or E90000 even on a "no code" bootsector (just as you posted ) for the tested MS OS's, while this is happily ignored by FreeDOS.

rloew, on 12 January 2012 - 12:16 PM, said:

The Magic Bytes are for Boot Sector Validation only.

Yep , but as seen we need to have at them for FreeDOS anyway, while the tested MS OS's happily ignore them.

Last two items seems to me like a nice contradiction (and no-end loop kind of situation).

On the other hand it provides a nice way to have volumes that are accessible/mountable only on FreeDOS (AND NOT on MS OS's)..... and another kind of volume that can be accessed only on MS OS's (AND NOT on FreeDOS) .... pretty much unuseful, if you ask me, but still some interesting news.

(and also a way to have a volume accessible from XP - and possibly later - MS OS 's, BUT NOT from DOS 7.x - and possibly earlier)

jaclaz

This post has been edited by jaclaz: 12 January 2012 - 12:56 PM

[dencorso]

For PC-DOS 1.00 and 1.10 (and, I presume, for all the OEM MS-DOS 1.xx versions) there is no BPB, nor the Magic Bytes, *and* DOS uses the first byte of the first FAT (on FAT-12, BTW, the only FAT they know about) to establish what's the floppy format. This causes WinImage to be unable to open dikette images of such OSes, because WinImage relies on the existence of a BPB. When a correct BPB is artificially added to either a PC-DOS 1.00 or 1.10 bootable diskette image (and there is free space for a BPB in them), then WinImage will read them with no complaints, regardless of the existence of the Magic Bytes. This tests were performed with v. 8.5.0.8500 and 8.0.0.8000 of WinImage, so I believe it may be true, at least, for all of v. 8.x.x.x, and probably to earlier versions as well.

[rloew]

jaclaz, on 12 January 2012 - 12:47 PM, said:

rloew, on 12 January 2012 - 12:16 PM, said:

No Windows 9x tests?

No, I thought that DOS 7.1 would have done for the moment.

Not quite. Windows does it's own checking in IOS.VXD and VFAT.VXD so there is room for more discrepancies.
I have already created Partitions that looks like FAT12 to one and FAT16 to the other.

Quote

rloew, on 12 January 2012 - 12:16 PM, said:

The BPB is the block starting at Offset 0xB only.

And what about this?
http://homepage.ntlw...name-field.html

Doesn't change anything but adds one more thing to worry about. I've seen the code that does these checks in my research.

Quote

Where does the actual BPB end?
Theoretically at 0x24

For FAT12 and FAT16. FAT32's BPB ends at 0x40.

Quote

It seems like we have to consider the existence of a "real" BPB AND of an eBPB (extended Boot Parameter Block)
http://support.micro...kb/140418/en-us
(and consequently "divide" the set in BPB and eBPB)

Some of the eBPB is also validated such as the Signature Byte. The ID is important to Windows for Volume discrimination.

Quote

rloew, on 12 January 2012 - 12:16 PM, said:

The Jump Bytes are part of the Code and FAT Validation.
In a non-Bootable Partition or disk, the Jump Destination does not matter.

Yep , but as seen we need to have at least EB0090 or E90000 even on a "no code" bootsector (just as you posted ) for the tested MS OS's, while this is happily ignored by FreeDOS.

rloew, on 12 January 2012 - 12:16 PM, said:

The Magic Bytes are for Boot Sector Validation only.

Yep , but as seen we need to have at them for FreeDOS anyway, while the tested MS OS's happily ignore them.

Last two items seems to me like a nice contradiction (and no-end loop kind of situation).

On the other hand it provides a nice way to have volumes that are accessible/mountable only on FreeDOS (AND NOT on MS OS's)..... and another kind of volume that can be accessed only on MS OS's (AND NOT on FreeDOS) .... pretty much unuseful, if you ask me, but still some interesting news.

(and also a way to have a volume accessible from XP - and possibly later - MS OS 's, BUT NOT from DOS 7.x - and possibly earlier)

jaclaz

Another scheme to enforce DRM?

[jaclaz]

dencorso, on 12 January 2012 - 01:43 PM, said:

For PC-DOS 1.00 and 1.10 (and, I presume, for all the OEM MS-DOS 1.xx versions) there is no BPB, nor the Magic Bytes, *and* DOS uses the first byte of the first FAT (on FAT-12, BTW, the only FAT they know about) to establish what's the floppy format. This causes WinImage to be unable to open dikette images of such OSes, because WinImage relies on the existence of a BPB. When a correct BPB is artificially added to either a PC-DOS 1.00 or 1.10 bootable diskette image (and there is free space for a BPB in them), then WinImage will read them with no complaints, regardless of the existence of the Magic Bytes. This tests were performed with v. 8.5.0.8500 and 8.0.0.8000 of WinImage, so I believe it may be true, at least, for all of v. 8.x.x.x, and probably to earlier versions as well.

I guess we are not targeting DOS 1.x, though, so I would say that we do need a BPB anyway.

rloew, on 12 January 2012 - 05:20 PM, said:

Another scheme to enforce DRM?

Naaah, I don't think there is any conspiracy , just "normal" stupidity/crazyness of non-standards or undisclosed/undocumented properly ones.......

Back to business,
A non-bootable bootsector needs to:

• start with E9 (or EB0090) <- to comply with the MS DOS 7.x (and hopefully earlier) and XP (and hopefully later) OS
  
• have anyway the Magic Bytes 55AA <- to comply with FreeDOS "quirk"
  
• since the OEM name is only checked during booting there is no need for it
  
• valid BPB data (from 0xB to 0x24)

let's go on with the eBPB:

Field                  Offset   Length
-----                  ------   ------
Physical Drive Number    36        1
Current Head             37        1
Signature                38        1
ID                       39        4
Volume Label             43       11
System ID                54        8

• Physical Drive Number is seemingly only meaningful for bootable devices (so it can stay 00 for the non-bootable one)
  
• Current Head is OK left as 00 in any case, though we may add to the description it's use as "dirty flag"
  
• Signature (NT Signature) any reason to prefer 0x28 over 0x29 or viceversa? (I remember seeing only 0x29 in "real life" bootsectors) <- needed for compatibility with NT (and hopefully later)
  
• ID is this "needed" or a 00000000 would do as well?
  
• Volume Label, even if it is not used anymore it could be set to something more meaningful than the "NO NAME"?
  
• System ID: Definitely "FAT12 " or "FAT16 "

Comments, ideas?

@rloew
Can you detail any findings you may have handy about IOS.VXD and/or VFAT.VXD behaviour?

jaclaz

[rloew]

jaclaz, on 13 January 2012 - 10:20 AM, said:

rloew, on 12 January 2012 - 05:20 PM, said:

Another scheme to enforce DRM?

Naaah, I don't think there is any conspiracy , just "normal" stupidity/crazyness of non-standards or undisclosed/undocumented properly ones.......

Didn't say anyone actually did, but it is another opportunity.

Quote

Back to business,
A non-bootable bootsector needs to:

• start with E9 (or EB0090) <- to comply with the MS DOS 7.x (and hopefully earlier) and XP (and hopefully later) OS
  
• have anyway the Magic Bytes 55AA <- to comply with FreeDOS "quirk"
  
• since the OEM name is only checked during booting there is no need for it
  
• valid BPB data (from 0xB to 0x24)

EBxx90 is OK.
Valid BPB from 0xB to 0x40 for FAT32. DOS will support a FAT32 Superfloppy, Windows will not.

Quote

let's go on with the eBPB:

Field                  Offset   Length
-----                  ------   ------
Physical Drive Number    36        1
Current Head             37        1
Signature                38        1
ID                       39        4
Volume Label             43       11
System ID                54        8

• Physical Drive Number is seemingly only meaningful for bootable devices (so it can stay 00 for the non-bootable one)
  
• Current Head is OK left as 00 in any case, though we may add to the description it's use as "dirty flag"
  
• Signature (NT Signature) any reason to prefer 0x28 over 0x29 or viceversa? (I remember seeing only 0x29 in "real life" bootsectors) <- needed for compatibility with NT (and hopefully later)
  
• ID is this "needed" or a 00000000 would do as well?
  
• Volume Label, even if it is not used anymore it could be set to something more meaningful than the "NO NAME"?
  
• System ID: Definitely "FAT12 " or "FAT16 "

Comments, ideas?

Signature must be 0x29 for proper operation with Windows 9x.
ID 00000000 is OK as long as only one Partition with that ID is mounted. Windows can get confused if more than one Partition share the same ID.
System ID can be "FAT32".

Quote

@rloew
Can you detail any findings you may have handy about IOS.VXD and/or VFAT.VXD behaviour?

I've mentioned most of my related findings in the last few Posts. Most of my research was concentrated on adding Terabyte support and Large Sector support.
I haven't done much research on Floppies or SuperFloppies. There are additional Kernel components involved with them as well.

[jaclaz]

rloew, on 13 January 2012 - 01:17 PM, said:

EBxx90 is OK.

An E90000 is not?

rloew, on 13 January 2012 - 01:17 PM, said:

Valid BPB from 0xB to 0x40 for FAT32. DOS will support a FAT32 Superfloppy, Windows will not.
.....


System ID can be "FAT32".

Yep, for the moment I am still in the FAT12/16 only realm.

rloew, on 13 January 2012 - 01:17 PM, said:

ID 00000000 is OK as long as only one Partition with that ID is mounted. Windows can get confused if more than one Partition share the same ID.

Yes, hopefully you have only one of these mounted at a time, but generating a "random" ID is not a problem and "safer". BTW and OT, ever heard of a "collision"?

rloew, on 13 January 2012 - 01:17 PM, said:

Signature must be 0x29 for proper operation with Windows 9x.

Let's make it 0x29 then, though I still wonder WHAT used 0x28....

rloew, on 13 January 2012 - 01:17 PM, said:

I've mentioned most of my related findings in the last few Posts. Most of my research was concentrated on adding Terabyte support and Large Sector support.
I haven't done much research on Floppies or SuperFloppies. There are additional Kernel components involved with them as well.

Yep, I was trying to avoid the need to dig up a Win9x to test, but I will do it like this, I wll make the non-bootable floppy sector based on the data we have till now, and then people may be able to test an image with it on a few systems .

thanks for the insights.

jaclaz

This post has been edited by jaclaz: 13 January 2012 - 01:55 PM

[rloew]

jaclaz, on 13 January 2012 - 01:54 PM, said:

rloew, on 13 January 2012 - 01:17 PM, said:

EBxx90 is OK.

An E90000 is not?

Of course it is. I didn't mention it because you already had it covered when you said "Start with E9".

Quote

rloew, on 13 January 2012 - 01:17 PM, said:

ID 00000000 is OK as long as only one Partition with that ID is mounted. Windows can get confused if more than one Partition share the same ID.

Yes, hopefully you have only one of these mounted at a time, but generating a "random" ID is not a problem and "safer". BTW and OT, ever heard of a "collision"?

Of course I have. Collisions are a big problem if you clone a drive and have both present. My next release of RFDISK has built in checking and repair options for Collisions.

[jaclaz]

rloew, on 13 January 2012 - 08:26 PM, said:

Of course I have. Collisions are a big problem if you clone a drive and have both present. My next release of RFDISK has built in checking and repair options for Collisions.

Yes , that is expected (collisions when cloning in some situations), I was talking of actual "by chance" collisions, more curiosity than anything else, the ID is 4 bytes, thus min 00000000 and max FFFFFFFF, i.e. 4,294,967,296 available values, but 4,294,967,296 to 1 against though pretty rare is not "nearly impossible", and since the ID/Volume serial is not "random" but is calculated, as seen on the little "reversing" spreadsheet I made:
http://www.msfn.org/...297#entry980297
chances are much bigger that that.

jaclaz

[rloew]

jaclaz, on 14 January 2012 - 05:35 AM, said:

rloew, on 13 January 2012 - 08:26 PM, said:

Of course I have. Collisions are a big problem if you clone a drive and have both present. My next release of RFDISK has built in checking and repair options for Collisions.

Yes , that is expected (collisions when cloning in some situations), I was talking of actual "by chance" collisions, more curiosity than anything else, the ID is 4 bytes, thus min 00000000 and max FFFFFFFF, i.e. 4,294,967,296 available values, but 4,294,967,296 to 1 against though pretty rare is not "nearly impossible", and since the ID/Volume serial is not "random" but is calculated, as seen on the little "reversing" spreadsheet I made:
http://www.msfn.org/...297#entry980297
chances are much bigger that that.

jaclaz

I have never noticed an accidental non-cloned collision. Since they are typically generated from the current date, a non-cloned collision can only occur in one of four ways.

1. Using a formatter that zeroes the ID or sets it to a specific value.
2. Using Partitions formatted with different algorithms. Rare unless #1 is true.
3. Sharing disks with someone else who formatted at the exact same time.
4. Formatting two partitions within a second of each other. This happened when I first added my anti-collision code to RFDISK. It updated multiple Partitions to the same ID..

[jaclaz]

rloew, on 14 January 2012 - 11:37 AM, said:

3. Sharing disks with someone else who formatted at the exact same time.

I was saying something slightly different, the Volume serial is a form of hash of actual date/time, i.e. the same serial can be generated on different date/times.

If we use some fantasy it is not difficult to increase dramatically probabilties of a collision.

Let's say that an employee in a Swiss watchmakers company was told to format a floppy and save to it his morning work just before lunch (or let's assume that a batch including a format command was scheduled to run every day at EXACTLY 12:30 ).
Notwithstanding the high level of precision of the guy (or of the scheduler) while the actual job is started exactly at 12:30,00, the actual format command is executed with a delay variable between 0 and 99 hundreths of second.
Another employee of the same company is tasked every month to store the images of the floppies, and, in order to identify them uniquely, uses the volume serial.

What will happen on August 1st, 1992? (with data of July 1992)

The probabilities field is a highly slippery one , but my guess is that probabilities of a collision in this scenario are very, very high, actually you have a very high probability of having at least one collision.

See the attached spreadsheet.....

Happy F9ing ....

jaclaz

Attached File(s)

•  Volchances.zip (27.48K)
  Number of downloads: 6

[dencorso]

@jaclaz: I just found some minor mistakes in Known_floppies.xls:

The 320k formats use 1 (not 2) sectors per FAT-12, and the 360K uses 2 (not 3) sectors per FAT-12.
All FAT-12 formats above 180k and below 1.2 M use 2 sectors per cluster.

The Table below is quoted from Thom Hogan's "The Programmer's PC Sourcebook", 1st. ed., Microsoft Press, 1988 (ISBN 1-55615-118-7) Section 2, p. 61.

 Twain3.gif (68.86K)
Number of downloads: 10

[jaclaz]

dencorso, on 23 January 2012 - 09:50 PM, said:

@jaclaz: I just found some minor mistakes in Known_floppies.xls:

That's good, can you post a copy if the spreadsheet with the corrections (manually typing the correction replacing the formula and making the cell, say, RED background?

dencorso, on 23 January 2012 - 09:50 PM, said:

The 320k formats use 1 (not 2) sectors per FAT-12, and the 360K uses 2 (not 3) sectors per FAT-12.

I'll check . (and see what I can do with the formula)

dencorso, on 23 January 2012 - 09:50 PM, said:

All FAT-12 formats above 180k and below 1.2 M use 2 sectors per cluster.

Hmmm.

jaclaz