Jump to content
Sign in to follow this  
taipan

Missing files

Recommended Posts

Guest Frustrated...

Flo,

you should definitely DO something, if a lib fix isn't coming soon.

1. The problem should be made public - for many people rely on your program for backups...

so tell 'em what to do to get at least usable disks. And not here in the forum, the program

should tell them!

2. DON'T tell after verification, that everything went fine. Hint to the possible problem, if you

can't evaluate correctly.

3. If the problem is always the alphabethical last folder, add a dummy one "zzzzzzz" which

contains just one text file "problem.txt" : This folder and file are added because of a

problem of the used library, which had not been resolved by the company since ...

Hope you'll get the stuff right, for I'd love to use your soft again,

MAG

Share this post


Link to post
Share on other sites
Guest LostFiles

I was trying to burn a slipstream of Xp with the service packs, and ever time it completed when i loaded the drives to test them, they showed blank.

After loading isobuster i saw all the files. I ran the burn again incase i made a mistake and the same occurance, empty CD looking at it from windows. So i decided to create and iso from the files, and then burn the iso to the drive. This looks to be working with no file loss.

Share this post


Link to post
Share on other sites
Guest Chema

I usually burn a lot of files, so I hadn't noticed this until today, in which I put only one file and a directory on the root, and by chance took a look after the verification. The directory wasn't there. =/ I guess I should check everything I've burned since... ouch, since when does this happens anyway? Someone mentioned seven months, so it's probably some more than that...

And what would be the quickest way to find other coasters? I'd rather not do it by hand. :P I figured I could Explore the DVD, select all files, check their Size on disk in Properties, compare it against the Used space reported in the Drive Properties and check for a mismatch, which for missing big files or directories is quite obvious, like today's coaster:

Drive Used Space: 4,683,544,576; Size on disk: 2,684,022,773

but not so for others, since the Used space includes the TOCs, which can vary a lot, so I couldn't be sure if a small file is missing:

DVD with a pair dozen files:

4,430,342,144 - 4,429,688,832 = 653,312

DVD with a hundred:

3,205,994,496 - 3,204,083,555 = 1,910,941

I can't do a directory comparison either, since most the files have been deleted from my hard drive. ^_^

For reference, you can see the DVD was almost full (4,683,544,576) and I renamed both the directory and the file inside CDBurnerXP.

This is not, however, *that* bad since seems all missing files can be accessed with IsoBuster or such. Still, it definitely warrants at the very least a big warning inside CDBurnerXP, as suggested.

Oh well, I guess I'll jump to InfraRecorder, at least until we know what exactly triggers this. A true shame, since I think your work is, not state of the art, but simply a work of art Flo. ;)

Cheers, and tell that vendor not to take the three programmer virtues so literally!

Share this post


Link to post
Share on other sites
Guest Psyrnge

I'm shocked. Thoroughly. I don't know what to say, really.

Over the last two weeks, I burnt 20+ data DVDs using CDBurnerXP. Since the respective data is pretty important to me, I used data verification, and also made some random tests to make sure that the burning worked, before I deleted the files from my HD. Three days ago, when I burned a DVD with only six files, I noticed that one was missing on the disc. I wondered what had happened, but since the data verification hadn't reported any problems, and I didn't see any reason to mistrust CDBurnerXP, I concluded that it had to have been a user error and that I probably forgot to include that particular file in the compilation. After all, if there *was* a problem of CDBurnerXP missing files, I wouldn't be the only one who noticed that, and the programmer would certainly inform his users about a bug of such severity, if not pull the software altogether. Or so I thought.

Today I noticed another missing file, and now I got curious and decided to check the forums. To my great surprise and shock, I found out that ...

1. CDBurnerXP has an ongoing problem with missing files for at least several months now. Fortunately the files appear to be physically present on the disk, but can't be recovered without the use of special software, which still makes the burned DVD pretty much worthless, and burning DVDs with CDBurnerXP a risky business.

2. The CDBurnerXP programmer, although knowing of the problem, did neither warn his users about it, nor did he take any other visible step to fix it. The only reaction seems to be that it is out of his hands because the bug originates from a third-party library. Flo, while it may be true that fixing the bug is out of your hands, warning your users about the problem before they burn dozens of DVDs with faulty filetables certainly isn't. I'm shocked and, frankly, disgusted about the way how this significant problem has been withheld from the users who don't regularly scrutinize the forums.

The problem is exacerbated by the fact that the software itself claims that the burning process worked without errors, so unless you count the number of files on the disc, you're lulled into a false sense of security that everything worked alright. I'm sorry to say that under these conditions, and at least in my opinion, Flo shares the responsibility for all the faulty DVDs that people produce because of this bug. I can't understand why the faulty funcionality wasn't blocked or at least the users warned about the problem.

As a hobbyist programmer myself, I don't usually complain about freeware programs. I realize how much work people put into them and if I don't like one, I can simply use another, no damage done. Come to think of it, I don't recall *ever* complaining about freeware program since I started with computers in 1984. But I've never been so disgusted by a freeware program's behavior in all these years either. The point is, this time there *is* a bit of damage being done, in the form of 20+ faulty DVDs and in the time I'll need to fix this mess - and the fact that the developer could have easily prevented all this by adding a simple popup to his program that warned about the bug, but yet decided to do nothing despite having full knowledge that people must be producing faulty DVDs because of this bug, is making me angry.

I'll probably wait some days, giving my emotions the chance to settle, before I do anything else than writing this post. At the moment I'm contemplating writing a mail to the services that host and sometimes even recommend CDBurnerXP - many of them add short reviews to their downloads, and in its current state, it's safe to say that the software is overrated. If the developers fails to warn the users about a significant problem that makes his program unreliable, then perhaps at least the reviews can be amended, so that future users can be protected from burning dozens of faulty DVDs, as I did.

In the meantime, I'll start to recover missing files from two dozen DVDs, and re-burn them correctly, this time. Needless to say, I won't be using CDBurnerXP for that task, since my trust in the program's reliability and in the developer's sense of responsibility has been thoroughly shattered by my recent experience. Thankfully there seem to be alternatives around; InfraBurner looks pretty decent (being Open Source and having received an update just last week), and perhaps I'll test some others as well. At present I'd regard any program that can reliably burn my data on a DVD, with a correct filetable, as an improvement, no matter how many other features it may be missing.

Sorry for the rant, Flo, but I hope I explained myself well enough to make you understand why I feel this way. If you need any more data about this bug (circumstances, hardware specs, etc.), just ask - being angry and disappointed won't stop me from helping you to fix it if I can.

Share this post


Link to post
Share on other sites

I fully understand your feelings. I don't want to add warnings though, until I actually understand what is going on.

Anyway, I'll spend some time on this issue this weekend, and with a bit of luck I might at least be able to indicate which files will not be burned to disc.

Share this post


Link to post
Share on other sites

Well, so far I believe that the problem is that I don't know anything about the issue, because no one bothered providing any details (or doing any further tests). I don't know whether or not it occurs for certain file system combinations, for CDs or only DVDs, with or without multi session. It would also help to know if older versions of CDBurnerXP (with an older burning library) also have this problem.

Without any information on reproduction of the issue, I cannot even verify if a change I make fixes the problem. In other words, it is virtually impossible for me to work on this issue currently.

Share this post


Link to post
Share on other sites
Guest Psyringe
I fully understand your feelings. I don't want to add warnings though, until I actually understand what is going on.

Well, may I ask why? What do you gain by not informing your users about a risk that has been proven to exist? And what would be so bad about it that you don't want to do it?

The only possible downside of such a popup is that it might reduce people's trust in the reliability of the program. However, I can assure you that people's trust is reduced *far* more if they experience the bug by themselves, without having been warned about it.

Imho, adding a popup would not only control the damage that the bug is doing (and it has done damage for months now, and continues to do so while we're discussing the issue here). It could also help you to analyze the problem by encouraging people to provide you with their data.

Example: Imagine that the following popup text occurs when the users wants to burn a DVD:

"Warning: Due to a bug in a third party library, CDBurnerXP might currently miss files when constructing the filetable of the DVD. The files will be physically present on the disc, but can only be accessed with special tools like IsoBuster. Since the 'data verification' algorithm will not notice if files are missing, we recommend to manually check whether every file has been added to the disc's filetable. If you don't want to risk burning a disc with a faulty filetable, you can create an image file first and then test its filetable with IsoBuster before burning it.

Note: If you encounter this bug, please consider helping us to fix it by sending us the following data: Your operating system, the brand and model of your DVD burner, the version of CDBurnerXP you're using, and the faulty filetable. You can extract the filetable from the disc by (...)"

The last part assumes that a method exists by which the filetable of a disc can be extracted into a file that's small enough to send it to you. Since (as far as I understood the issue) the bug only affects the UDF filetable, and other filetables on the same disc are unaffected, it could help analysis a lot if people could send you this data. You'd then have the faulty UDF filetable and the correct filetable in another format, and see exactly which files are missing.

Share this post


Link to post
Share on other sites
Guest Psyringe
Without any information on reproduction of the issue, I cannot even verify if a change I make fixes the problem. In other words, it is virtually impossible for me to work on this issue currently.

Sorry for the double post, I saw your second post only after I wrote my previous one. I'd just like to add one bit.

Question: Can't you see that your policy of withholding the information from your users is directly *responsible* for your lack of information which you now lament?

Your program has a serious bug which is difficult to reproduce. You will need the help of your users to track it down, yet you refuse to even inform them about it. Then you lament that your users provide you too little information to work on the issue. Do you see the logical fallacy here?

Furthermore, what is the logic in first saying "I don't want to inform the users before I know what's going on" and then saying "I can't determine what's going on because I don't get enough feedback from the users"? Isn't it obvious that you're creating a vicious circle here?

You need to tell people about the problem so that they can *look* for the data you need. You need to specify which data you're looking for. And you need to tell people how they can provide you with that data with minimal effort - the easier you make it for the users to provide that data, the more data you'll get.

I get the impression that currently you're burying your head in the sand while knowingly letting people walk straight into the trap. I'm pretty sure that this strategy will never solve the problem, it will only make matters worse.

Without any information on reproduction of the issue, I cannot even verify if a change I make fixes the problem. In other words, it is virtually impossible for me to work on this issue currently.

Sorry for the double post, I saw your second post only after I wrote my previous one. I'd just like to add one bit.

Can't you see that your policy of withholding the information from your users is directly *responsible* for the lack of information which you now lament?

Your program has a serious bug which is difficult to reproduce. You will need the help of your users to track it down, yet you refuse to even inform them about it. Then you lament that you have too little information to work on the issue. Do you see the logical fallacy here?

You need to tell people about the problem so that they can *look* for the data you need. You need to specify which data you're looking for. And you need to tell people how they can provide you with that data with minimal effort - the easier you make it for the users to provide that data, the more data you'll get. Look, I thre away a couple of DVDs which suffered from the "missing file" bug just some days ago. Had I known that you were willing to analyze them in order to fix the problem, I would have saved them, tried to find a tool to extract the filetables, and sent them to you.

I get the impression that currently you're burying your head in the sand while knowingly letting people walk straight into the trap. I'm pretty sure that this strategy will never solve the problem, it will only make matters worse.

Again, sorry if I'm being blunt, but I really don't see the logic (or merit) in your way of approaching the problem. I think your approach exacerbates the problem, and perhaps someone needs to shake you out of that hole that you dug for yourself.

Share this post


Link to post
Share on other sites

Hehe, I see the point you are trying to make. I can't deny that there's some truth to it :)

Still, I do not want to show a warning without *any* kind of specifc reason. The warning would be seen by everyone, even though it might only affect a fraction of those. Instead, currently an additional verification process comes to my mind, which just counts the files and folders at the end of the burning process and compares it to the expected value. I believe that this could actually detect when the problem happened, and at the same time, there is no unnecessary confusion invoked.

Share this post


Link to post
Share on other sites
Guest Psyringe
Instead, currently an additional verification process comes to my mind, which just counts the files and folders at the end of the burning process and compares it to the expected value.

That would definitely be an improvement. Whether it's a better option than a general popup depends on how many users are actually affected by the bug, which nobody currently knows, so both approaches are justifiable imho.

Make sure that you're checking *all* the filetables on the disc, since (IIRC) we already have reports of people who say that the UDF filetable is missing files while the Joliet and ISO filetables are correct. That may also be the reason why the current data verification algorithm doesn't catch the bug, it might be using the ISO filetable where the bug never seems to occur.

Ideally, the added verification routine would produce a log with useful information which the user can then send to you; and if the program finds missing files, it would inform the user about the problem and tell him that he could greatly contribute to solving it by mailing the log to you. (Theoretically you could even build an auto-error-report feature based on the existing auto-update feature, so that logs and relevant information are automatically sent to your server if the user agrees to that, but that might be overkill.)

Sorry for the copy/paste mess in my previous post btw, unfortunately I'm writing these posts as a guest and therefore can't edit them. :(

Share this post


Link to post
Share on other sites
Guest taipan (not logged in)
Instead, currently an additional verification process comes to my mind, which just counts the files and folders at the end of the burning process and compares it to the expected value. I believe that this could actually detect when the problem happened, and at the same time, there is no unnecessary confusion invoked.

Flo, to my disappointment I ask myself why this comes you to your mind so lately (you'll understand if you take a look http://forum.cdburnerxp.se/viewtopic.php?f=3&t=7207&sid=c51fdb2403f6a3f07d00abc070e84050&start=15#p27157HERE). Don't get me wrong, but to be more precise, i.m.h.o. you could have prevented leaving several of the preceding post's authors stranding by following my suggestion months ago...

Share this post


Link to post
Share on other sites

As I am not working full time on CDBurnerXP, some issues might take a while to really get my attention. Especially such demotivating issues, where you already know that you're powerless for the most part.

Share this post


Link to post
Share on other sites
Guest ManiacDC

Hi Flo,

I wish I could provide more details, but I've ran into this in the past (over a year ago) and am running into it again (probably due to the fact I haven't burned any DVD's with folders until now). Whenever I use the UDF Filesystem on DVDs all but 1 of my folders is missing (not sure about CDs). In the past when I tried IsoBuster I could see all the folders on the disc, but in Windows Explorer I couldn't (I did not try this recently). To workaround this issue I simply use ISO9660/Juliet rather than anything with UDF.

Thanks, I hope this helps a bit.

Maniac

Share this post


Link to post
Share on other sites

Burned a DVD with 2.84GB with many small files and included folders.

OS: Win XP Pro SP3

DVD drive - LiteON LH-20A1S

CDBurnerXP version 4.2.5.1490.

Burned without closing disc so more files could be added.

Burned on speed 6 and also checked Verification checkbox, everything went fine, verify succeeded.

And later found that all the files in the inner folder are missing when opening the disc with Windows Explorer.

But when opened the disc with CDBurner to look if I can add files - I see that all the lost files are there! So I tried to add some dummy.txt file to the inner folder, hoped that it will make reimport the filetable from the previous session and so make the lost files visible. Burned again with verification. Everything went fine, but result - no files anyway.

So I was desperate, launched Ashampoo Burning Studio 2009 Free edition (which had failed me many times for screwing multisession discs - just some write error on the end of the session) and told to continue my multisession disc. Ashampoo told me that there are some Root file with zero size which Ashampoo is going to overwrite with some 80KB Root. Ok, allowed to overwrite. And again - all the lost files were visible in the Ashampoo compilation window. I added a dummy file again. Burned. Phew! Finally I got all the files back. There were some duplicate files in the root of the disc, though, but the files in the inner folders were visible, hooray.

So this time CDBurnerXP let me down a bit.

When I tried (just for a curiosity) to import the session of the disc again with CDBurnerXP after I had added a file with Ashampoo, CDBurner told me: Session could not be imported: invalid UDF tag. Ok, it was not a surprise that CDBurnerXP is not compatible with Ashampoos style of writing UDF sessions :D

Anyway, hope my story will somehow help to fix that UDF lost files problem.

Share this post


Link to post
Share on other sites

I experienced this kind of problem many times in the past weeks, and now I have other informations that I hope could be useful

1- The files added to a multisession DVD aren't shown in Windows Explorer (XP Pro SP2). The same on XP Home SP3

2- Such a kind of DVD isn't recognized by Vista at all ("Insert disk into drive E:")

3- Linux is able to see all the files without any problem (openSUSE 10.3)

4- If you add other files through Nero Burning, after this operation, and ONLY on the PC you used to burn, all the files appear until you restart the PC (could this be a kind of cache behaviour?)

Couldn't be this problem a UDF problem?

Which UDF version is used by the burning library?

Using CDBurnerXP 4.2.5.1490 on WinXP Pro SP2

Share this post


Link to post
Share on other sites

Hi vix,

I'm having the same problem. Multisession is not correctly updating the disk so you can see all the files or non of the files.

CDburnerXP 4.x is not working correctly. I believe it has to do with the UDF system. Other folks are having the same issue.

I was having

this problem with DVD-R and DVD+R disks using 3.5.x.x.x I used the file checking system (Close last session) in the disk

Info menu. (Close last session) needs to be put back into the program in order to correct this problem for now.I use it for

DVD's when after burning DVD's and the DVD show no files. Close last session fixes this problem !!!

Now the problem has moved into the 4.x.x.x versions! Using close session in 3,5 alpha does not effect adding more files

later.

It's effecting standard CD-R disks too. Flo's going to have to find out what's causing this problem.

I'm, in the mean time, will be going back to the OLD program 3.5 alpha to use CDBurnerXP with framework 1.1so not to

waste any good DVD's or CD's! :) I hope this helps.

Share this post


Link to post
Share on other sites

Unfortunately, it seems like NumediaSoft has not changed anything in this regard with their latest version, at least I have been able to reproduce the issue once with their new SDK. We'll see how that develops...

Share this post


Link to post
Share on other sites
Guest JCW

>>Unfortunately, it seems like NumediaSoft has not changed anything in this regard with their latest version, at least I have been able to reproduce the issue once with their new SDK. We'll see how that develops...<<

Well, I'm really glad that you're finally coming to grips with this problem, Flo; otherwise I really like your software. I hope you'll keep us posted on progress toward a solution. Meanwhile (although I hate it), I'm using Nero 9 for multi-session burns. (Sorry!) -- JCW

Share this post


Link to post
Share on other sites
Guest cdpaul

Hello,

I would like to know if that "missing file" problem has been seen on one-shot DVDs (write and finalize), or if it only bugs on multi-session.

Thanks.

Share this post


Link to post
Share on other sites

It might be that I have a solution for this problem now (missing files after burning a second session). I'll add the possible fix to the next version, would be great if someone could verify it.

Share this post


Link to post
Share on other sites
Guest vries9999

Sorry to say, but the problem is not yet fixed :( in the 4.2.7.1801

After burning adding some files to a multisession cdrom the message box

"the number of files does not match the expected file count:

Expected filecount: 265

Actual filecount: 84

appears.

Although the number of files match.

The difference between the actual and expected is always the number of files added!

Share this post


Link to post
Share on other sites
Guest hornster

I double that with regret. I wrote a dvd with 4.2.7 (just downloaded), an old video project of a friend of mine, consisting of 12 avi files of about 355 MB each with variable name lenght + 12 srt files (subtitles for the videos) with also variable name lenghts but all of them long and descriptive and with spaces. All of the files were in a directory whose name consisted of 9 symbols with no spaces (numbers, letters and one dash). Used the default file system (ISO+Joliet+UDF). In the end nothing appeared on the DVD. IsoBuster showed (and recovered) the files under ISO and Joliet but not under UDF. Hope you fix it, this bug destroys a great piece of software. Good luck.

Share this post


Link to post
Share on other sites
Guest kyu
Hello,

I would like to know if that "missing file" problem has been seen on one-shot DVDs (write and finalize), or if it only bugs on multi-session.

Thanks.

Well, I've not experienced any missing files so far, but something that may be related. I am using CDBXP 4.2.7.1801.

I use DVD+RWs to burn video files (AVI) downloaded from onlinetvrecorder.com and watch them on my DVD player. Once I've viewed the videos I re-use the DVD+RWs. My normal procedure is to burn the videos with verification enabled, tell the program to finalize the disc (as it is going to be deleted anyway after the videos have been viewed) and after the burned medium verifies ok I delete the files from my hard disk. When I click "burn" and CDBXP tells me that the medium contains data and asks me whether it should delete it I confirm that, using fast delete. Then everything seems to be working fine, the medium gets erased, burned, verification runs (although the latter is extremely slow - takes way longer than the burning itself). However, when the process is finished I get a message like the following almost every time:

The data has been written correctly to the disc, but the number of files does not match the expected files count. Most likely, the file system structure has not been written correctly and some files will not appear on the disc.

Expected file count: 8

Actual file count: 11

The "Expected file count" is the correct number of files in my compilation - so note that the verification process claims more files on the disc than there should be. The first few times this occurred I re-burned the +RW, and in most cases the file count would then be correct. As the problem persisted nearly every time I burned one of my video media, at some time I checked the freshly finished medium after getting an error message similar to the one quoted above - and lo and behold! - not a trace of the additional "phantom files" counted by the verification routine! All the files played correctly on my DVD player.

Now, while I have not experienced any data loss (and fortunately I have not burned any really important data with CDBXP so far, just my videos), I must say that not being able to rely on the results of the verification routine is a grave problem, grave enough to make me lose trust in a program that I had initially been quite pleased with. This is aggravated by the fact that verification takes about three times as long on my new PC with CDBXP as it did with my ancient Nero 6 on the equally ancient notebook I used for burning before.

As otherwise I like CDBXP a lot I am sorry to say that I will have to switch back to my old Nero version which, although outdated, does everything I need at this time and provides me with reliable results.

Kind regards

Volkhart

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.