Jump to content
Sign in to follow this  
brit0n

Bootable Disk - Boot Image Date/Timestamp

Recommended Posts

OK. Back to a standard El Tortito boot disk with a 2.44MB DOS boot image (.img) containing all the good DOS files and the remainder of the CD containing lots of other good stuff.

 

So I create the .IMG file and point ImgBurn at it for the:

 

Advanced | Bootable Disc | Boot Image

 

at that .IMG file.

 

I leave:

 

Advanced | Dates | Volume Dates

 

empty as it was when I found it.

 

I leave:

 

Advanced | Dates | Folder/File Dates

 

radio button "Use File Date & Time" selected as it was when I found it.

 

I compile my El Torito bootable disk ISO file and hey presto! (hey li chee? any Rupert fans out there?). All is fine and everything works. However, for no reason that I can tell, if I then break the .IMG file back out of the ISO, it and its associated BootCatalog.cat file both have a date 31 years ahead.

 

Actually, not EXACTLY 31 years.

 

Latest example I have is:

 

IMG File Created: Today, April 02, 2007, 10:34:51

IMG File Modified: Same as "Created"

 

IMG/CAT File from ISO Created: Monday, January 18, 2038, 22:14:08

IMG/CAT File from ISO Modified: Same as "Created"

 

If I did something wrong, I can't think what. If not, although somewhat erudite, "it's a bug and it undermines the security of the software which will deter people from depending on it for anything important" (well, I'm quoting someone who made a lot of money out of good software but I can't remember who and I aint gonna look it up! lol).

 

No panic cos the average user wouldn't know how to find it, but if it's as easily fixable as it is repeatable, I'm sure it will get done sometime.

 

(Note that ImgBurn creates the BootCatalog.cat which is new to me as I always had to provide it before and now it won't accept it if I include it in the same directory as the IMG file so the error is probably only in the IMG file stamp unless in creating the CAT file, it copies its stamp back to the IMG file which would be a trifle odd.)

 

(As far as I have so far checked, all the other file date/timestamps match the original files used for the build.)

Edited by brit0n

Share this post


Link to post
Share on other sites

There's no date field (that I can see) in the structures for ElTorito. I certainly don't do anything with dates anyway.

 

My Guess is that whatever you're extracting them with is just making a date up.

Share this post


Link to post
Share on other sites

OK

 

[RESOLVED] (actually no bug then!)

 

It doesn't stop ME trusting ImgBurn OR IsoBuster (can't find anywhere it's mentioned there either so I guess it's simply a stray dog because El Torito is a hack or a kludge or something - amazing we are still playing with floppy disks when the drives are museum pieces anyway lol)

Share this post


Link to post
Share on other sites

OK I checked El Torito and you are right (why wouldn't you be! lol but I know in your situation it's nice to get confirmation).

 

Although it doesn't say, I guess that the reason there is no dating of the IMG and therefore the "fake" CAT) when it is injected is that it isn't a file so it doesn't matter what it's original attributes were.

 

Likewise, when IsoBuster reads the ISO and states the size of the IMG, where it would normally show the date-timestamp (as the BootCatalog.cat above it does), instead it has a note stating that the size is the format size not necessarily the real size.

 

While I am mentioning size, have you considered what will happen if someone sets the size of the bootable "floppy" to a size that doesn't match the image file size? (I have run too many tests to do it right now, but an example would be me leaving the drop-down box set at 1.44MB and then pointing to a 2.88MB IMG file. Even if ImgBurn takes care of it (or throws up one of those great "because I am a nice program" dialogs (nice touch! lol), it would still be better that it sets display to 2.88MB when you set the image file to that size. Just pernickety to put somewhere at item no. 5,983 on your to-do list :D

Share this post


Link to post
Share on other sites
amazing we are still playing with floppy disks when the drives are museum pieces anyway

We aren't.

 

Regards

Share this post


Link to post
Share on other sites
amazing we are still playing with floppy disks when the drives are museum pieces anyway

We aren't.

 

Regards

 

You may be - we aren't (well, except when our clients need us to).

 

El Torito standard for booting disks requires the use of a floppy image. If you have a bootable disk, you have a floppy image on it - you can't SEE it, but it's there. If you only use Linux, you are still using an old-fashioned DOS type diskette image.

 

It's a hack/kludge to enable bootable CDs and since it works, noone has bothered to come up with another standard which would have to be ground into everyone past all their complaints.

 

Got a better idea? Let's have it!

Edited by brit0n

Share this post


Link to post
Share on other sites

A lot of bootable CD's use their own custom loaders - i.e. the Windows install CDs.

 

That's just a few sectors worth of data that boots the kernel loader or whatever and not an entire floppy disc image.

 

You can of course also make an image of a HDD partition and put that on the CD as the boot image.

Share this post


Link to post
Share on other sites
Sign in to follow this  

×

Important Information

By using this site, you agree to our Terms of Use.