Dawudd Posted December 14, 2009 Posted December 14, 2009 Steps to reproduce: Select any mode where the output is an image file. Set the image filename to something that has non-Latin characters (e.g. אבג.iso). Note that the Destination field displays the correct desired filename. Build. Expected result: The image is created with the proper Unicode filename.Actual result: An error dialogue displays:Unable to create or replace file: C:\...\???.iso Reason: The filename, directory name, or volume label syntax is incorrect. Cancel the error dialogue. Note that the Destination field now displays ‘???.iso’ for the filename. Thank you.
LIGHTNING UK! Posted December 14, 2009 Posted December 14, 2009 Works fine here - using the exact name you specified. Are you running it on an old OS or something? Win 2000/XP/Vista/7 are needed for Unicode to work properly. Are you using the latest version - 2.5.0.0?
Dawudd Posted December 14, 2009 Author Posted December 14, 2009 Works fine here - using the exact name you specified. Are you running it on an old OS or something? Win 2000/XP/Vista/7 are needed for Unicode to work properly. Are you using the latest version - 2.5.0.0? I should have specified OS and version. Sorry. This is 2.5.0.0 on XP SP3 (English). Unicode seems to work perfectly in other areas. I have no idea why this would work correctly for you and not for me. Are there any other data that you need to track this down? Thanks, and thank you for your prompt reply.
LIGHTNING UK! Posted December 14, 2009 Posted December 14, 2009 Are you saving to a FAT32 drive or have any other 'file spliting' option enabled? The program isn't being forced into 'compatiblity' mode of any other OS? (The top few lines in the log window would tell you that)
Dawudd Posted December 14, 2009 Author Posted December 14, 2009 (edited) Are you saving to a FAT32 drive or have any other 'file spliting' option enabled? The program isn't being forced into 'compatiblity' mode of any other OS? (The top few lines in the log window would tell you that) NTFS, the error still occurs when file-splitting is set to ‘None’, and compatibility mode in the Properties dialogue is not enabled. There is also no mention of it in the log. The whole log from another attempt is attached. ImgBurn.log Edited December 14, 2009 by Dawudd
LIGHTNING UK! Posted December 14, 2009 Posted December 14, 2009 Please configure build mode to the point where it won't work (i.e. specify the destination path like you said) and then save to a project file and upload it. If the ibb file doesn't contain the correct name then it's out of my hands - something must be messing with the combobox your end.
Dawudd Posted December 15, 2009 Author Posted December 15, 2009 Please configure build mode to the point where it won't work (i.e. specify the destination path like you said) and then save to a project file and upload it. If the ibb file doesn't contain the correct name then it's out of my hands - something must be messing with the combobox your end. OK. Saving the project with a Unicode filename also worked correctly, by the way. As for the combobox, I noticed that the non-Latin characters change to question marks immediately after I press the large Build button. If I track down what on my system is messing with the combobox, I will post an update. Thanks again. אבג.ibb.txt
LIGHTNING UK! Posted December 15, 2009 Posted December 15, 2009 As the IBB contains the correct name, it's not your combobox that's at fault (assuming you always fill it out in the same way you did that time of course?). Can you now please try making a file of the correct name (i.e. make a new text file in C:\ via the explorer context menu and rename it to 'אבג.iso') on your hdd before you hit the build button and attempt to build a new image of the same name. What happens when you do that?
Dawudd Posted December 15, 2009 Author Posted December 15, 2009 It worked! I also deleted the image afterwards and rebuilt it, and the error repeated. So the problem happens only when the file does not already exist.
LIGHTNING UK! Posted December 15, 2009 Posted December 15, 2009 It can only be due to the function that expands environment variables in the path name then... but that gets used all over the place - although perhaps not in places you'd notice it. For some reason, yours is using the Ansi version rather than the Wide one. As you can reproduce this easily I'll have to send you a special version with extra debug code in it to double check the dynamic link to the Wide version of the function in the dll is working properly and a few other things. Can you PM me a decent email address to send it to please? (Assuming you don't mind getting to the bottom of the issue of course)
Recommended Posts