brit0n

OK I lost you. I DID use the NAS. The IMG file came from the NAS, the content files came from the NAS and the ISO went to the NAS. Then the burn was from the ISO which was still on the NAS. Why would I try it from the PC hard disk partitions instead? Well, to see if it was all that LAN/NAS stuff which meant that ImgBurn took no less than 1 hr 21 mins 27 secs to parse the file system from Device Ready status to starting the verification! At that rate, it would be quicker to copy the whole thing to hard disk, build, burn, verify and throw the ISO back at NAS afterwards and probably save more than an hour. But without testing it or getting an explanation here that the 1hr 21mins is NOT caused by the PC to NAS to PC to NAS during the parsing. It sure as heck isn't the burner! Anyway, my only point was to request progress status updates even during phases which others may not find longer than a matter of a few seconds if there is ANY chance of users having configurations which might last more than an hour! (Most users would have reported this as a bug wouldn't they? I mean it SEEMS as though it HANGS for that time - if it does, let me know.) Thanks.

These are extracted lines from log to save you searching through the guff.... I can send the whole thing if you want (see note at end): I 16:38:03 Operation Started! I 16:38:03 Building Image Tree... I 16:38:15 Operation Successfully Completed! - Duration: 00:00:11 I 16:38:15 Operation Started! I 16:38:15 Writing Image... I 16:46:25 Operation Successfully Completed! - Duration: 00:08:08 (USER DELAY) I 17:11:39 Operation Started! I 17:11:39 Filling Buffer... (20 MB) I 17:32:48 Operation Successfully Completed! - Duration: 00:21:09 I 17:32:48 Cycling Tray before Verify... W 17:32:54 Waiting for device to become ready... I 17:33:01 Device Ready! ---------------------------------------------------------------------------------------------- SOME PROGRESS INDICATION WOULD BE NICE HERE (Parsing File System...) Could be either "Parsing File System..... 0%" in status bar or else a progress bar. ---------------------------------------------------------------------------------------------- I 18:54:28 Operation Started! I 18:59:05 Operation Successfully Completed! - Duration: 00:04:37 Delay probably caused by ISO being in CIFS on a NAS partition so there is LAN delay as well as translation of filesystem(s). However, original files were in CIFS through the LAN and ISO was saved to CIFS through the LAN and that didn't take any time at all! Some time, I'll do a comparison with an identical operation but moving/copying the files from NAS to hard disk partition, build, save ISO to hard disk, burn from hard disk and then move/copy the ISO to NAS but I am reasonably certain it will be a lot faster! Still, progress indication would be good compared with either checking LAN bandwidth usage or running to another room to check the NAS device activity lights lol (Thanks for great program with some very clean coding! Sometime I'll search to see whether you have posted what language you code in and what builder you use etc. If you haven't, could you?)

OK I think I found it. In case anyone else finds lowercase directories/files in DOS but can't get anything in DOS except the DIR of the root, here's the problem. Pure ASCII isn't pure of course. I had read that ASCII was the standard and being new to ImgBurn, wasn't even sure what "Standard" was. For DOS boot, the defaults need to apply although I am working with the Win98SE version of DOS and that is happy with the "no filename extensions setting" (well, so far at least and I used 8.0 filenames for some identifiers although I am now sticking a .ID on them for future runs. DOS boot MUST have: Advanced | Restrictions | ISO9660 | Character Set | Standard and NOT ASCII. (Anyway, not such an ImgBurn newbie now, but would anyone like a see-through rewritable CD? )

Not sure but I thought the idea of the Standard specifying an Extended Attribute Record was that any filesystem could then specify attributes according to its taste by defining them and then allocating them in the file section. How the heck you do that if there is no standard, I don't know - it would mean that a disk burned with one burning program might become a nonsense on another UNLESS each burning program then reads the definitions and changes them into its own type. Not exactly a "standard Standard" but then it was supposed to be a one-size-fits-all kind of thing. Anyway, if I find the method they intended, I'll post here as you may have saved me a lot of time by so swiftly getting ImgBurn to the top of the test scores in my other tests lol

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

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)

Thanks. brit0n loves regediting lol (well, at least I know what I am doing... er sometimes lol) Well, you live and learn. You mean they actually came up with a Standard which didn't like files without extensions? Sheesh! That's one check box I have to fill! (You might see my note about file attributes in the bugs forum. It was interesting to note that under IS09660 you can even attribute "file associations" so I guess they were all wrapped up with the dot3 thing lol.)

Yeah, that's what I thought. But that's all I changed. Checked that box to disable UDF and bob's your auntie it worked. The lower case was weird - it was like I was running a version of DOS I never had. I can't think how to repeat "my error" but if it happens again, I'll double-check the settings on the Joliet tab. Now I have the expected result (very nice piece of program coding you have here I have to say), I can't think how or why I would unless you want me to TRY to emulate it! I have a feeling it was simply something I set which is no longer set that way. Is there something I can find in the log which will tell me the file system settings I used? I can only find where it states: "Image File System(s): ISO9660 (Bootable), Joliet, UDF (1.02)" which doesn't tell me much (the successful build was "Image File System(s): ISO9660 (Bootable), Joliet" I don't know how you managed to get yours to display lower case filenames once booted into DOS, because mine certainly didn't. If you relax the ISO9660 spec restrictions when you build, I guess that might be possible, but then you always run the risk of the parser not working correctly. Maybe I did that, but the log doesn't tell me and if I did, I can't think how it got set back again unless ImgBurn "reverts" when closed. And I can't think that building from an NTFS filesystem on the PC running ImgBurn and building from a Network Attached Storage device using CIFS and NIFS. Let's assume I relaxed the file settings and sorry to waste your time. Now that would mean that I set them to something acceptable. But there isn't a "Reset to Default" button. What are the defaults? (Meanwhile, I'll try again with UDF enabled just to see if it does it again.)

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.)

Or anything? What about Extended Attribute Record in the File Section? But then you have to HAVE a File Section and you have to maintain compatibility across the entire filesystem which is probably why hardly anyone does it unless they are paid a lot to do it! Or am I barking up the wrong tree-hugger? The PRIMARY attribute under ISO9660 is whether the "file" (directory entry) is a directory or not (if it is NOT then it is a FILE - I know some might read this and laugh their arses off, but I am sure YOU know what I am saying without expanding lol). On the same logic, surely "Hidden" would be the same as saying that the file "exists for the user" meaning the Existence Bit has a value of 1 in the Extended Attribute Record? This isn't my field, but I can't think what else the following would mean: Existence Bit: If set to ZERO, shall mean that the existence of the file shall be made known to the user upon an inquiry by the user. If set to ONE, shall mean that the existence of the file need not be made known to the user. Hope this helps. Don't bother to give a lengthy explanation if I am wrong - just say "Nope, you are wrong"

[sOLVED] OK let me shout "Duh!" and go all red-faced. I just ran an unverified build and burn and it's fine. UDP disabled - I was actually wondering when I saw lower case directory names in DOS. So the solution is simple - disable UDF when building. ---------------------------------- Now for the explanation (I think). Unlike Nero Burning ROM which used to allow setting all the filesystems even if they couldn't be used, I hadn't realised that ImgBurn was "strict" (which is good actually and I am impressed provided that strictness to standards is consistent). I don't know if ImgBurn is "thinking Linux" and if that means that UDF is OK for bootable disks, but for any El Torito boots which can end up in DOS (which means MOST if not ALL Emergency CDs) would need to have the UDF disabled. Might I suggest that when: Advanced | Bootable Disc | Make Image Bootable is CHECKED (TICKED), then the program automatically defaults: Restrictions | UDF | Disable Unicode Support to CHECKED (TICKED) also? Perhaps with a simple text addition (there's loads of space on that tab) stating that Unicode Support should ONLY be enabled if the disk is not required to be booted into DOS and then accessed. (Or alternatively and IMHO preferably, reverse the checkbox to be clear as default for bootable disks and would have to be checked/ticked to ENABLE Unicode support.) Just a suggestion.

Yeah - that's El Torito for ya! lol El Torito sticks the contents of the Boot Image (in this case 2.88MB) in as A:. Can't see them in the directory structure of the CD - it's an IMG file you insert and it can only be seen with an ISO buster like ISOBUSTER and the files in it - DOS boot and DOS utility files - can only be seen if you then break the IMG out - ALL of which I do in XP or Vista but right now in XP as I am still tinkering with tests in Vista before any prod machines use it). It disables the "swap diskette" drive (normally B:) and uses that for a FDD (if you have one). No idea what you mean. I'm not messing with a real floppy. I keep a diskette on one box on the LAN for those odd times when it's needed (normally to aim at it without a diskette in it when testing some software tricks which need a physical FDD to do some things even without a diskette). It SHOULD be able to read ISO9660 and Joliet but not UDF. I did my learnin' burnin' years ago with Roxio, then Adaptec (both yucky). Then when I started making bootable CDs, slipstreamed OSs and now boot USB sticks based on El Torito, I almost exclusively used Nero Burning ROM. Trouble is that I just got the OEM bundle of it and it doesn't HAVE Burning ROM - only Nero Express without the ability to make bootable CDs (did Nero forget why they became successful? lol) and I'd have to shell out even more money for the Vista version of Nero. Now with multi-boot partitions on all the boxes with Vista, XP, 98SE, DOS and Linux, getting one piece of software which will work on XP or Vista and create CDs for all the partitions means I am testing several burning programs. ImgBurn looks like it's ahead of the pack but it has some odd quirks and if this one isn't my mistake, I probably have to move on. Shame - it's a darned nice piece of software WHICH TELLS YOU WHAT IT IS DOING which is getting rare these days with the "we think for you idiots cos you don't understand our software" mentality lol Wow! Not sure why you would want to do that! I only throw these old systems on the boxes so that software which CLAIMS to be able to run on old OSs actually can for reporting to others about them. Also because there really is some software which has never been replaced successfully but which has not been upgraded to work in new OSs. Good luck going back past Win98SE though! Thanks for the swift reply. Actually I am trying another version of the burn (I'm up to 4 so far in ImgBurn which is less than the other programs needed to get this far, but they are keeping other boxes busy lol!) I'll post a [sOLVED] if I find the answer.

Brand ImgBurn newbie but been reading a lot Can't find the answer to this but if it's there, accept my apologies. OK. I was testing ImgBurn to see if it could do some things. First up, I created an El Torito Bootable Win98SE CD (data type) - first of all on a CDRW until I have sorted out some of the layouts in the 2.88MB bootable image. Compiled OK and burned. Booted into it which throws it into a good old-fashioned DOS prompt based on Win98SE (without loading windows). I can see and use all the non-NTFS/non-linux partitions as expected. But for the CD itself, I can DIR it but if I try to change directories to something other than root, it says it can't find it. (Yeah, I checked how it was typed etc etc.) (It reads fine in Windows itself.... this is the clue?) Is this likely to be something I messed up in the ISO9660/Joliet/UDF settings? I thought the defaults would be OK! Or is it a Standard v. ASCII thing? I thought straight ASCII was the right setting. I've burned it on an old Mitsumi CR-4804TE (CD burner) and a new(er) Lite-On LH-20A1H (DVD Burner) both of which produce this kind of compilation using other software. Is there something I should know about ImgBurn that is different or have I misclicked a setting somewhere and if so how do I find out what! Any help (or pointers to where in the Forums I missed the answer ) gratefully received. (Yeah and why am I forbidden to change my signature? lol)