|
A sort.txt is supposed to sort the files by where you place them according to your numbers. You "should" be able to even place a higher weighted file at the top of the list and it should be burned first (as long as you give it a higher number), so the actual placement in the list in not what's supposed to matter, but rather the number you give it in the sort.txt.
However, this is not the case. You can have 1256 files in your sort.txt and you can number the 1st_read.bin "1" and the dummy "1256" and the dummy will still end up somewhere toward the middle and the 1st_read.bin will probably end up somewhere toward the beginning, (exactly the opposite of where you placed it).
The way the lba comes into play is this. If you're making a sort.txt using the structure of a CDROM, you "copy tree info to file releative path", and it will save that info in the directory you specify as "filelist.txt". This file has all the lba's of the files. When you run F2S.exe on it, the files will ba placed in order of lba's from the highest to the lowest and numbered from 1 to ???.
It has been my experience as well as the experience of many others, that the -sort option in mkisofs is not reliable. Just do a google search for "mkisofs sort" and see how many results you get that are ppl asking the same question I posed earlier.
Is there a way to make mkisofs sort the files accurately, (meaning the way ACTUALLY DICTATED by the sort.txt)?
-Ex
|