Why is InCD writing so often to my harddisc? I know it is writing log files. But why every other second? And why does the log file in the Program Files/Nero/InCD folder sometimes includes parts of HTML-code of internetsites I've visited or includes text of cookies on my computer?
I don't like that at all!

I just updated to version 4.1 and it's the same problem in this new vesion.

Because it's allocation file space without mandatory writing to it, thus getting random data from deleted files of the harddisk (yes we shall fix that, really) and because I think, not 100% sure, it's logging some not very usefull failure of Test Unit Ready commands (fails because there is nothing in the device - well, as said, not very useful to know).

(in reply to henkl)

Thanks for your answer. I look forward for the next version.

(in reply to henkl)

The file that is actually written to every second, is: \Windows\InCD\error.log. It writes 'Created MMC writer class ... ' for my CD writer and 'Created MMC reader class ... ' for my DVD player, again and again. This file doesn't contain info left over from an old file. But the file \Program Files\Ahead\InCd\Error.log does.
Thanks again for working on these problems.

(in reply to henkl)

I have also just installed 4.1 and noticed this disk access problem. If I put the log file in question into the recycle bin the disk access stops. Will this cause other problems?

(in reply to henkl)

In my case, the filename is \Windows\InCD\incderr.log.
The repeat entry is

c16b2a70 03:12:15 23:13:13:00 e=0. Created MMC writer class for SONY CD-RW CR
X225E.
c16b2a70 03:12:15 23:13:13:00 [Fine]e=2502. <Error text lookup failed>((Sns:2
, Asc:x3a, Asq:x0 ) @ Port:0, bd:0, ID:1, Lun:0)

My specifics are:

AMD K6 450 MHz processor
376 MB
Samsung SW-408B CD-RW
Sony CRX225E CD-RW
Windows 98SE
InCD 4.1.0.0

(in reply to henkl)

quote:

---

Originally posted by harper

I have also just installed 4.1 and noticed this disk access problem. If I put the log file in question into the recycle bin the disk access stops. Will this cause other problems?

---

Deleting the log file probably broke the error logging mechanism. An interesting way to workaround the problem. I although fear that at next start the log file will be recreated.

(in reply to henkl)

quote:

---

Originally posted by dburg

Deleting the log file probably broke the error logging mechanism. An interesting way to workaround the problem. I although fear that at next start the log file will be recreated.

---

The log file is indeed recreated at each startup. The disk access can be turned on and off by simply moving the file incderr.log out of the folder \Windows\InCD\ and onto the desktop or anywhere else. Disk access and logging resume if the file is placed back into its original folder. Strange.

Thanks for the reply, Dave.

(in reply to henkl)

quote:

---

Originally posted by dburg

Because it's allocation file space without mandatory writing to it, thus getting random data from deleted files of the harddisk (yes we shall fix that, really) and because I think, not 100% sure, it's logging some not very usefull failure of Test Unit Ready commands (fails because there is nothing in the device - well, as said, not very useful to know).

---

Any estimate as to when the patch to fix this problem will be available?

(in reply to henkl)

Actually I would like to take care myself of the issue as soon as formating issues are resolved on all devices. Unfortunately there seems to be lots of possible configurations. :-/

Fix for disc access might not be possible in next InCD update, but in the one after that.

(in reply to henkl)

Thanks again for the response, Dave. I'll just keep looking for updates.

(in reply to henkl)

Once Again,

You won't see "ANY OTHER" software company online, giving answers, and trying to find solutions to users problems...... What a great company, and a "fantastic" piece of software......

Thanks for being there and helping us out as needed..... This is why I "ONLY RECOMMEND" ahead sofware for any burning needs........

(in reply to henkl)

Hope it's OK to say that this thread continues here

(in reply to henkl)