GNOME Bugzilla – Bug 508654
Windows-compatibility doesn't truncate 64+ characters files
Last modified: 2008-01-26 14:30:42 UTC
When burning a data project containing files with names over 64 characters, pressing the Windows-compatibility button yields the warning that those filenames will be truncated to 64 characters. Brasero doesn't actually go ahead and do that, but instead when pressing the Burn button it will display a similar error message again and turn-off the windows-compatibility feature if you continue.
Thanks again for reporting the bug and sorry for the delay. I would need additional information here please Denis. Could you tell me the names of your files and the layout of them so I can test it at home. Thanks.
It's very simple to reproduce. Create a tmp directory, then create an arbitrary file in it. Rename that file to a name longer than 64 characters. Then launch brasero, select "data project" and add the tmp directory above. You'll get the > 64 warning, but it is merely a warning. If you try to burn it though, this turns into an error, hence the inconsistency.
Denis, I asked you what name you gave to your file because I really can't reproduce it. Sometimes, names can trigger strange bugs. Anyway could you send me the usual log please created with "brasero -g > log 2>&1" Thanks in advance.
NOTE: I have fedora 8 too.
I Named it "1234567890" repeated 9 times :-) Some more additional information: in the burn dialog: select "increase compatilibity with windows". If you try to burn to a file, the burn button is grayed out, and stays that way even if you remove the compat option (i guess that's another bug). If you burn to CD, you get a warning, followed by another warning that prompt to continue without windows compat. This is inconsistent, it should either rename the file OR not let you continue to the final burn sequence. hope this helps :-)
Created attachment 103598 [details] log from brasero when in shows the second msg used brasero -g > log3 2>&1 used two different files with long file name in directory tmp, it looks like the file name collides with itself? anyway it says it couldn't make the session so can't burn that
Created attachment 103599 [details] log from brasero, this time it works ok used brasero -g > log4 2>&1 now those files are NOT in any directory and it shows only the first message when checking compatibility checkbox, everything else works fine (this also works for files which have difference after 70. character, they are renamed and used correctly if they are NOT in the tmp dir)
This is interesting bug, I tried many variations and came to this: -when the files are not in directory, its ok -when the files are in directory (I tried tmp), I get that message AND it doesn't burn because I tried 2 files with long name, difference is behind 70. character; also strange thing happens when the difference is prior to the 20. character, it looks like collides with itself (see the log) -when using libburn backend it works fine, I saw that when upgrading my brasero and now finally tested: >> To enable libburn backend you need to activate it in GConf: >> /apps/brasero/config/libburn_burn >> /apps/brasero/config/libburn_iso so try libburn BTW after testing this I got also other strange things/bugs like it can't burn some file even after I deleted it from burn compilation or many duplicate files/dirs when storing the compilation and loading again. Gnomebaker couldn't even initialize my drive with cdrecord and swapped out 2/3 of my RAM (testing those two 5B files). I'll investigate these bugs later, guess I had just bad day...
I finally reproduced that bug and I think I fixed it in SVN stable (0.7 branch). It was triggered by the use of md5sum-file plugin (that creates a md5 file on medium) that didn't copy properly the track it was passed. Thanks for your help and information that was helpful. As for the other bugs you mentioned, file as many as you can =). Denis, the bug regarding the "burn" button grayed out when choosing image output in dialog seems to have been fixed. I close this bug and this fix will be in upcoming (tomorrow?) 0.7.1. Feel free to reopen it if I miserably failed.
> Feel free to reopen it if I miserably failed. Philippe, I feel the force in you. You will succeed.