488mbs won't fit on 700mb CD??

[Des]

I've never encountered this before:
I have a folder with 488mbs of jpeg files on them. I have Verbatim and Sony CD-Rs that hold 700mb. On two computers using either disk and trying to burn first with Burnawre and then with Imgburn I get an error that there is not enough room on the disk??

Any insight?

I solved the problem by splitting the folder into two parts and using two disks, but still I am baffled.

--dES

[Nelson37]

Possible one of the files is corrupted, I've had this happen before. Copy the files to a new directory in small chunks and check size regularly.

Also check for hidden files.

Are these a very large number of files? There is a limit to number of files in a root directory, 512 IIRC, use a subdirectory or split into several.

[Des]

Thanks for the quick reply Nelson37. There are 185 files in the folder which I labeled as Photos.
None of the files seem to be corrupt, that is they open in Irfanview (I used thumbnail and slide show view to check, figuring in the slide show iview would report an error). Not sure about hidden files. My default on the machines I use is to have Windows 'Show Hidden Files and Folders' and I'm not seeing any.
When I moved them from one machine to the other I used a 4gb USB stick and dragged the photos folder onto it, and then dragged the folder again to the desktop of the other machine.

--dES

[DB83]

Take a quick look to see how much disk space those 185 files actually take. There may be an inefficient file-storage FAT in play.

[Des]

Take a quick look to see how much disk space those 185 files actually take. There may be an inefficient file-storage FAT in play.

Well, the folder is 488mbs. Burnaware says the folder requires 522mbs of disk space. Imgburn states folder is too big for media and asks if I want to overburn.

Not completely sure what you mean by 'inefficient file-storage FAT ' At least not in this context.
Both computers are running XP SP3 and their drives are formatted to NTFS. The USB drive I used to move from computer A to Computer B is formatted FAT 32, I don't think that's a factor here.

I think Nelson37 may be right about a corrupt file and I'm just not seeing it...

--dES

[DB83]

It was but a suggestion. A quick check of the folder's properties would tell you how much disk space is actually being used rather than the sum of the 185 files.

I have a folder of 3900 images. Size is 528 meg. Actual disk space used is 536 meg. So in your example 488 meg using, it seems, 522 meg is not as efficient. That could be down to the importing of FAT32 files in to a NTFS disk.

But even so there should still be enough space on a 700 mb disk.

[El Heggunte]

Regarding "corrupted files"... More probably, a corrupted filesystem?

Have you already run chkdsk What does it say?

[mgh]

Any system showing such weird behavior deserves to be checked thoroughly for viruses/trojans etc.

[Nelson37]

Two different PC's, this has to be a problem that travels with the files. Virus is ALWAYS a possibility.

Divide and conquer. Make multiple subdirectories, or just groups, and add them to the burn job a chunk at a time. Check the job size and compare with the listed file size on disk. There is some overhead, but somewhere you will get a large, unexpected increase in file size.

I would also suggest making the subdirectories as COPIES of groups of files, do not Move the files into the subdirectories. Check for file size variations when doing this, as well.

I would start with groups of files of about 100 MB each, roughly.

[Nelson37]

More questions - When Burnaware says it will take 522 MB on disk, what happens when you try to burn? Any error?

Also, what are the total file sizes of the two, separate disks?

[Des]

Wow, lot's of good questions and information, thanks all!
These are two of my computers at the shop. I left the folders in-place on the first machine, so to answer some questions I figure I would start Burnware again and make note of the error messages, etc. Ummm, interesting, this morning there is no issue. Burnaware reports that 488mb of files will require 488mb of disk space and happily went about burning the original folder.
At this point I am thinking Virus or Trojan as mgh and will also run chkdsk as El Heggunte suggested.
Depending on the results of these I will also go through Nelson37's suggestions.

Will post results, may not be able to until Monday though.

--dES

[jman98]

You definitely should run a good anti-virus program through the first machine just to be sure, but after that I would suggest that you make sure you have backed up anything on that PC that you can't live without. Behavior that strange where one day you get nonsense and the next day you get sensible behavior may be your only warning that you're close to a major failure of some kind, perhaps the disk drive.

[LIGHTNING UK!]

Perhaps your drive is just misreporting the space available on your disc and the files on your hdd are fine.

ImgBurn displays all the disc info on the 'Device' tab when you're in Build mode.

[Des]

Perhaps your drive is just misreporting the space available on your disc and the files on your hdd are fine.

ImgBurn displays all the disc info on the 'Device' tab when you're in Build mode.

But it happened on 2 different machines. One where the files/folder weere store originally and the other when the files were brought over via USB to a different machine.

I never thought to check the imgburn Device Tab But imgburn did state that the files would require 102% disk space.

--dES

[LIGHTNING UK!]

Clicking the 'Calculate' button back on the 'Information' tab will tell you exactly how much space the files themselves are taking up and then the size of the image (so that would be including the file system overhead).

It's knowing these exact figures that'll help you (and/or us) figure out where the problem was coming from. Post a screenshot of it or something. You could even just copy + paste the info from the log window.

[Des]

Clicking the 'Calculate' button back on the 'Information' tab will tell you exactly how much space the files themselves are taking up and then the size of the image (so that would be including the file system overhead).

It's knowing these exact figures that'll help you (and/or us) figure out where the problem was coming from. Post a screenshot of it or something. You could even just copy + paste the info from the log window.

Thank you again, I was hoping to be able to report more concrete info today but as stated above the problem seems to have corrected itself, which now gives me other concerns.
I will be able to try again in a few hours, hopefully I can get it to recreate the issue.

--dES

[El Heggunte]

OK, but besides checking the health of your HDDs (as jman98 wisely suggested), you should also take a closer look at other installed programs / running processes. Just as an example, one day I accidentally discovered that an "invisible instance" of MPC-HC makes ffmpeg sluggish --- and on my sister's computer (with 64-bit Windows 7), a poorly-written "desktop gadget" was making MinGW miscompile everything

[Des]

Sorry for the long delay, didn't have a chance to do much with this on the weekend.
Came in early today and the error still has not reappeared, sorry I did not make note of the logs and errors when this first occured on Friday.
Ran a virus/malware/trojan check and it came back clean.

Ran chkdsk and got a lot of Index Errors.

Ran a full chkdsk with /R and 90 minutes later everything seems to be good! Did not run a SMART check yet, but this evening I will image the drive to a portable for 'just in case' and run a SMART and maybe another virus scan.

Thanks to all, hopefully this was the problem...

--dES

[jman98]

If your chkdsk took 90 minutes then you are a lot closer to disaster than you realize. Your problems will continue on this drive and just get worse. Eventually I would expect it to fail to boot. The data will very likely be recoverable but unless you are a PC expert you will need professional help to do that. Again, you need to be sure that you have copied anything you care about from that drive as soon as possible.

[irondudetoo]

If your chkdsk took 90 minutes then you are a lot closer to disaster than you realize. Your problems will continue on this drive and just get worse. Eventually I would expect it to fail to boot. The data will very likely be recoverable but unless you are a PC expert you will need professional help to do that. Again, you need to be sure that you have copied anything you care about from that drive as soon as possible.

chkdsk /r = suface scan
90 minute chkdsk /r is not uncommon chkdsk+surface scan for a larger hd

[jman98]

chkdsk /r = suface scan
90 minute chkdsk /r is not uncommon chkdsk+surface scan for a larger hd

chkdsk /r does repair. So your assumption is that this was a simple operation of surface scanning with little to no repair and my assumption is that a good deal of repair was done. Then it depends on which of our assumptions are right.

[Des]

Ran HDDScan for Windows this morning on the system (been a stupid few days) and no errors were found.
I will take jman98 's advice and replace the drive as it is a little over 3 years old. I have imaged it and should be able to take care of the rest this weekend. Fortunately this computer is not used for any longterm storage of files.

Thanks all!!

--dES

Here is the SMART report:

[TBoneit]

Why not run the Western Digital diagnostics? That is what I would run on that drive.

[Des]

Why not run the Western Digital diagnostics? That is what I would run on that drive.

Honestly, I didn't think to

-dES