#54 1.5 udf format 2 sesssions causes file corruption

[Jim Michaels]

attached is my cdrtfe.ini

to reproduce:
1.get a 700MiB cd-r and insert it
2.drag 600MiB worth of windows installers, pdf files, and .url files to it, such as installers from sf.net
3.select the folder the files are in with ctrl-a
4.ctrl-drag them into cdrtfe
5.burn
6.click the big red X to zap all the files in cdrtfe
7.ctrl-drag a new installer to cdrtfe
8.burn
9. try to copy the files from the cd to the downloads directory in windows 7 or try to right click the file and pick run as administrator (you don't have to go through install, just cancel)

10.get another 700MiB cd-r and insert it
11.drag 600MiB worth of windows installers, pdf files, and .url files to it, such as installers from sf.net
12.select the folder the files are in with ctrl-a
13.ctrl-drag them into cdrtfe
14.burn
15.don't make any new sessions.
16. try to copy the files from the cd to the downloads directory in windows 7 or try to right click the file and pick run as administrator (you don't have to go through install, just cancel)

expected:
UAC should complain about the fact that you are trying toinstall a program and are you really sure you want to do this, etc.

actual:
steps 1-9...
windows 7 and IE band together and ban the program from executing or copying because of file corruption. i think windows 8 does this too. the error message complains about it being an "internet file" and that it's "corrupt". same goes with copying. apparently UDF format doesn't like multisession.
steps 10-16...
windows 7 gives you the normal UAC complaints when trying to execute. copying is not a problem

[Oliver Valencia]

Could you please specify how many files and folders you had in the first and second session?

Are the files accessible after step 5 before adding the second session?

Does the error only occur when accessing the files from the second session or are the files from the first session affected too?

I'm not sure, but this could be the same bug I am currently tracking down. It seems as if under certain circumstances mkisofs fails to correctly merge the previous and the new session. If this is the case, then it is not cdrtfe related as I have the same behaviour when using mkisofs directly without the frontend. Maybe you could try this too.

[Oliver Valencia]

[Oliver Valencia]

[Jim Michaels]

the cd was destroyed. but 2nd session didn't have the netzero executable and also had a .txt file rewritten I think.

the rest of the files in this attachment are essentially what was in the original session, minus the netzero file.

[Jim Michaels]

forgot to mention - rock ridge was also turned on with UDF. I don't know about cdrom filesystems and what to use with what discs for what purposes. maybe you could put that in the manual if you know near the top of the help or in its own section.

[Jim Michaels]

"are the files accessible after step5?" I am inclined to say yes,but I don't want to say yes without further testing because my memory is fading. I only have access to a win xp box at home,the 7 box was at someone else's house.
I could test on 8 as well I am sure (same effect I think), but I don't have a burner in that machine,it's IDE and can't buy IDE burner right now. becoming scarce too. after seeing the problems, I switched to pure UDF can't remember if I switched to pure UDF after or before the working disc,thought it was after, but not sure now. I have had quite a turbulent weekend overall.

Is there a way to simulate multisession with ISOs and mkisofs? win8 /might/ be able to detect the problem.

alas, I don't have easy access to test hardware.
If you have any other tests, tell me now.
I can re-enable rock ridge and try to re-burn a disc and try a test with single session.

[Jim Michaels]

Comparing 26 files with the source files ...

0 error(s) found.
this was the standard verify in xp after burn. we will see after placing in win7 box.

[Jim Michaels]

I may have to wait for windows 7/8 testing. I don't personally have a box for that. yet. do you? I could mail the cd-r if necessary if you have a box, provided you are in the USA.

[Oliver Valencia]

I can reproduce this under Windows XP and Windows 8 (Windows 7 not tested) with and without cdrtfe. So I think it is an mkisofs problem, even a very old mkisofs 2.0 from 2002 and genisoimage from cdrkit based on mkisofs 2.01.01a08 can produce a corrupted disc. Depending on the filesystem settings (ISO, Joliet, UDF) and the number of files the results are different. Sometimes only some files of the second session cannot be accessed, sometimes all new files aren't readable or, like in your case, even the files from the previous session are gone.
If I have found a simple and reliable test case, I will send a bug report to the author of the cdrtools.

[Jim Michaels]

cool.

[Oliver Valencia]

Ok, after intensive testing, I have to admit that this is indeed a cdrtfe bug. It seems to occur under quite rare circumstances, as this bug was introduced over 6 years (!) ago.

Until this is fixed, you shouldn't use the on-the-fly mode when adding sessions to a disc. Writing on-the-fly is safe for a single-session disc or for the first session of a multi-session disc.

[Jim Michaels]

OK. I was told not to use ISO burning when I had problems using ISO mode with it making unfresh multiborders. bug #3382858. the title was "adding new data files to multiborder not fresh". I will see if I can find the new bug number.

[Jim Michaels]

never mind, going from old memories, that was an invalid bug (bug#48). guess I will switch to iso mode for now until things are fixed.

[Jim Michaels]

ummm, cdrtfe /IS/ set for ISO. me confused. let me look at the .ini file I posted.

[Oliver Valencia]

So, after some more testing, I think I know what's going on. It seems as if we have two bugs here.

First one is in cdrtfe. When writing a disc on-the-fly without temporary image cdrecord needs to know the size of the data to be written. To determine the size in sectors mkisofs is called with the -print-size option. However, cdrtfe did not use the same filesystem options for this -print-size command and for the actual writing. As a result the calculated size was too small and cdrecord aborted the writing process too early. This caused some or all files of the second session to be corrupted. The data from the first session remained intact. This bug was independent from the actual filesystem settings, so it could affect any second session regardless of the filesystem (ISO9660, RockRidge, Joliet, UDF).

This bug should be fixed here:
http://home.arcor.de/kerberos002/download/cdrtfe-1.5.0.1-test3.rar
With this version you should be able to write multisession discs on-the-fly, except for discs with UDF as filesystem (see below).

The second bug seems to be a mkisofs issue, when appending sessions using UDF as filesystem. In this case the second session is ok and all new files can be read, while all files from the first session aren't accessible. Depending on the mkisofs version used to create the disc Windows will either throw an access denied error or it will complain that the file or directrory is damaged. This can even be reproduced when creating the disc under Linux. Until this is solved, UDF should not be used for writing multisession discs.

[Jim Michaels]

I disabled UDF checkbox which uses mkisofs -udf and put the alternative -UDF in settings for mkisofs. this seems to be a little different for multisession. so either give people a choice or switch to that one. apparently -udf (rational) is buggy, but -UDF is not. might want to notify the author of

-udf Generate rationalized UDF file system
-UDF Generate UDF file system

even though I turned on import previous sessions and am using TAO,
with -UDF, all old sessions' files can be seen in windows XP, but can't be opened/read, nothing happens. only the latest session is usable.

[Oliver Valencia]

I don't see the need to give a choice between -udf and -UDF. Both are the same except that 'file ownership and modes are set to more useful values' as the mkisofs man page says. Read the mkisofs man page for -r/-rational-rock for more details.

Both -udf and -UDF produce the same bug: When appending a second session, the files from the first session become inaccessible.

I have already informed the author of the cdrtools twice about this, on 23.03.2013 and 21.12.2014. I got no response. Maybe you want to give it try. When sending a bugreport to Jörg Schilling, you should have a very simple test case (just the pure mkisofs and cdrecord commands from the commandline, don't use any kind of frontends). Always use the most recent version of the tools.

I used the following test case (I have omitted the commandline output here, of course it should be included in your bugreport):

$ mkisofs -udf -rational-rock -volid Testdisk -output session-1.iso testfile01.txt

$ cdrecord gracetime=5 dev=0,0,0 -v -tao -multi session-1.iso

$ cdrecord dev=0,0,0 -msinfo

$ mkisofs -udf -rational-rock -volid Testdisk -cdrecord-params 0,12077 -prev-session 0,0,0 -output session-2.iso testfile02.txt

$ cdrecord gracetime=5 dev=0,0,0 -v -tao -multi session-2.iso

[Oliver Valencia]

Closing this as the cdrtfe related bug has been fixed with cdrtfe 1.5.1. The author of the cdrtools is aware of the UDF bug in mkisofs.