#1 Burning Software

Hi,

I've been thinking hard about it, but cannot come up with a satisfying solution. Currently, StarBurnX has a DataBurner for ISO/Joliet and an UDFDataBurner for UDF file systems. The problem is if you want to switch from one file system to another.

Using UDF as default will be "just fine" from a user's perspective, as it supports large files and unicode file names. In some situations though, like when burning bootable discs, the user needs to use an ISO/Joliet file system.

1. From your SDK's perspective, the user would need to make the choice first, and then add files and configure the boot image. This is not a good user interface though. The user should not be bothered with a file system prompt every time a new disc is being created, not only because selecting a different option is rarely necessary, but also because most users won't even know the difference and should not be confronted with terms like "UDF" and "ISO".
2. So my attempt would be to let the user select a file system later, if necessary. In fact, I can and actually do this with my current Numedia Soft SDK (which needs to be replaced) and would like to continue doing that with StarBurn. Since switching is not supported though, I only have the following options:
2a) Create a new DataBurner and add all files from any previous DataBurner object. This can be rather slow though, if many files have already been added to the compilation and/or the files were added from a slow source like a CD. I'd also consider this error prone, as you have to also copy boot image information and whatever else there is now or in the future.
2b) Create a wrapper for UDFDataBurner and DataBurner, which instantiates both of these DataBurners and performs all operations on the file system on both objects simultaneously. Then switching is an instant action, but as a consequence all operations would take twice as long and the app would need twice as much memory, even if the user never switches between file systems. (Though this is also difficult in case of >4GB files. I could add them to the UDFDataBurner, but not DataBurner. If currently working with UDF and later switching to ISO, how would the user know one file is missing? I'd need to keep track of such issues, and that somewhat exceeds the amount of work I intend to have with creating such a wrapper.)

So what should I do? Your SDK doesn't really give me a convenient option. Neither can I use bridged file systems in StarBurnX (which would solve my issues), nor is there a method to copy all objects from one DataBurner to another without requiring file system access.

A related issue is the fact that it is not currently possible to modify a DataBurner after burning or saving as ISO file (http://www.starburnsoftware.com/forum/starburn-sdk-f3/exception-when-adding-files-after-saveimagefile-t2206.html), unforunately even "by design" as the docs state. I also only have the possibility here to rebuild a DataBurner from scratch, which is too time consuming and cannot really be justified from a user's perspective. Even from a developer's perspective this limitation does not make much sense (even the by now crappy NMS SDK never had such limitations).

BTW, if this is any issue that can be solved by me paying you a certain amount of money, let me know how much you need

Hello,

So...

We use the virtual FS inside of the StarBurnX. We can extract this FS and make the independent FS object ( also we should "teach" the DataBurners to "understand" this external FS ). But UDF and ISO FSs have a different rules and these rules will be validated when FS will be attached to the specific burner ( not at adding file/foldes to FS as now )!!


Maybe the better solution is use the UDFDataBurner by default?! P.s. UDF disc can be bootable!

Is my explanation clear?!

Regards,

Dmitry

Yes, UDF is a good default. And yes, UDF discs can be bootable, but as far as I know, if you want to create an XP boot disc (for example) you need an ISO/Joliet FS and it won't work with UDF.



I don't think this is a problem. Example:
- Add file to UDFDataBurner: "VeryLongFileName.txt" (will be burned as is)
- Switch to ISO burner: Will be burned as "VeryLon_.txt" or similar
- Switch back to UDFDataBurner, requires that original file name is always kept in memory: "VeryLongFileName.txt" (will be burned as is)

So it doesn't really matter when the file names are validated, as long as the original FS structure is preserved for switching between burners.
The user may need to know which file names get truncated, however. This can also be done easily: Before burning, my app iterates over all existing file system objects and calls a function "GetImageName()" or similar (which does not yet exist in StarBurnX). This function would return the file name on the disc respecting the FS limitations. I could then compare the Name with the ImageName and check which file names get altered and my need attention from the user. GetImageName() could also return an empty string, if adding is not possible at all (>4GB or similar), maybe also returning an error code so I can display the right reason.

So in the above example GetImageName() would return "VeryLongFileName.txt" in the UDFDataBurner and "VeryLon_.txt" in the ISO-Burner.

Do you think that is possible for you to implement? Or are there problems with this approach?

Hello,

1) Yes, I guess it is possible to implement;

2) We may plan this feature on the 13.x ( as we don't have a time to implement it in v13, sorry );


Regards,

Dmitry

OK, thanks. Then let's get back to that after the V13 release.

Will this also solve the issue of not being able to modify the FS structure after burning? Or will you address this separately?

Hello,

2) I will try to solve this issue in v.13 release;

Regards,

Dmitry

So how does this work in v13 now? Don't see any new properties or methods in this regard.

Hello,

Unfortunatelly the "Virtual file system" is not implemented yet! This feature is in features list for the next version of StarBurnX!

Regards,

Dmitry

Any time frame yet? Don't make me wait another year please

No .. no .. not year!

I guess the next major version will be available after the several month!

Regards,

Dmitry

That sounds like a year to me actually (with delays included).

Hello,

You should hope for the best!!

Dmitry