Jump to content

Validate filesize in Build-Mode


Recommended Posts



I burned some files in Build Mode (ISO 9660 + Joliet) and everything seemed to have worked fine. But as I tried to copy these files back onto a HD it didn't work. Turns out that these files where too big (2147483648 bytes) for the ISO 9660 + Joliet filesystem and I should have burned them with UDF.

It would be nice if ImgBurn would warn the user about files that are too big for the chosen filesystem instead of producing coasters.



P.S.: Keep up the good work! :thumbup:

Link to comment
Share on other sites

It usually warns when building


At least for me it doesn't. Maybe I'm missing something in the settings?


I just tried it again. A single file, 2147483648 bytes big. ISO 9660 + Joliet. While Nero correctly says that it is too big, I am able to burn it in Build Mode with ImgBurn. (Direct burn, not writing an image)


Here's the log:

I 14:56:16 ImgBurn Version started!
I 14:56:16 Microsoft Windows Server 2003, Enterprise Edition (5.2, Build 3790 : Service Pack 2)
I 14:56:16 Total Physical Memory: 2.096.632 KB  -  Available: 1.602.724 KB
I 14:56:16 Initialising SPTI...
I 14:56:16 Searching for SCSI / ATAPI devices...
I 14:56:16 Found 1 CD-RW, 3 DVD-ROMs and 1 DVD±RW!
I 14:56:54 Operation Started!
I 14:56:54 Building Image Tree...
I 14:56:54 Checking Directory Depth...
I 14:56:54 Calculating Totals...
I 14:56:54 Preparing Image...
I 14:56:54 Checking Path Length...
I 14:56:54 Image Size: 2.147.549.184 bytes
I 14:56:54 Image Sectors: 1.048.608
I 14:56:54 Operation Successfully Completed! - Duration: 00:00:00
I 14:59:09 Operation Started!
I 14:59:09 Building Image Tree...
I 14:59:15 Checking Directory Depth...
I 14:59:15 Calculating Totals...
I 14:59:15 Preparing Image...
I 14:59:15 Checking Path Length...
I 14:59:15 Image Size: 2.147.549.184 bytes
I 14:59:15 Image Sectors: 1.048.608
I 14:59:17 Operation Successfully Completed! - Duration: 00:00:08
I 14:59:17 Operation Started!
I 14:59:17 Source File: -==/\/[BUILD IMAGE]\/\==-
I 14:59:17 Source File Sectors: 1.048.608 (MODE1/2048)
I 14:59:17 Source File Size: 2.147.549.184 bytes
I 14:59:17 Source File Volume Identifier: TEST
I 14:59:17 Source File Application Identifier: ImgBurn v2.3.2.0 - The Ultimate Image Burner!
I 14:59:17 Source File File System(s): ISO9660; Joliet
I 14:59:17 Destination Device: [1:1:0] BENQ DVD DD DW1640 BSRB (G:) (ATA)
I 14:59:17 Destination Media Type: DVD+RW (Disc ID: MKM-A02-00) (Speeds: 2,4x; 4x)
I 14:59:17 Destination Media Sectors: 2.295.104
I 14:59:17 Write Mode: DVD
I 14:59:17 Write Type: DAO
I 14:59:17 Write Speed: MAX
I 14:59:17 Link Size: Auto
I 14:59:17 Test Mode: No
I 14:59:17 BURN-Proof: Enabled
I 14:59:18 Filling Buffer... (128 MB)
I 14:59:21 Writing LeadIn...
I 14:59:22 Writing Image... (LBA: 0 - 1048607)
I 15:05:57 Synchronising Cache...
I 15:05:58 Closing Session...
I 15:05:59 Image MD5: a2579ddd605d1c9b6093b9dced35117f
I 15:05:59 Operation Successfully Completed! - Duration: 00:06:41
I 15:05:59 Average Write Rate: 5.322 KB/s (3.8x) - Maximum Write Rate: 5.638 KB/s (4.1x)

Link to comment
Share on other sites

That's true, but although I'm burning on Windows the DVDs might have to be read on Macintosh.

But I guess I can (and pretty much have to... ) live with how it is now. In the beginning I thought that ImgBurn made an error when in fact it didn't. (Read something about a limit in google and got an error adding those big files in Nero.)

Link to comment
Share on other sites

I'm pretty sure Mac does support UDF. That's why I said I can live with it. :)

I burned those files for a friend who has a Mac and he said he couldn't copy them. Then I tried copying them on Windows and it didn't work either. But now I can't reproduce the problem. The discs burned with ImgBurn and ISO 9660 + Joliet work just fine on Windows. Must have been a coincidence and it weren't the big files.

Damn, I guess ImgBurn doesn't have any bugs at all?! :o

Edited by sneaker
Link to comment
Share on other sites

  • Create New...

Important Information

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