After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 508654 - Windows-compatibility doesn't truncate 64+ characters files
Windows-compatibility doesn't truncate 64+ characters files
Status: RESOLVED FIXED
Product: brasero
Classification: Applications
Component: general
0.7.0
Other Linux
: Normal normal
: 0.7
Assigned To: Brasero maintainer(s)
Brasero maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2008-01-11 01:26 UTC by Denis Leroy
Modified: 2008-01-26 14:30 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
log from brasero when in shows the second msg (89.19 KB, text/plain)
2008-01-24 02:10 UTC, Jan Tichavský
Details
log from brasero, this time it works ok (148.72 KB, text/plain)
2008-01-24 02:14 UTC, Jan Tichavský
Details

Description Denis Leroy 2008-01-11 01:26:49 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.
Comment 1 Philippe Rouquier 2008-01-20 17:22:51 UTC
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.
Comment 2 Denis Leroy 2008-01-23 19:10:59 UTC
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.
Comment 3 Philippe Rouquier 2008-01-23 19:58:22 UTC
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.
Comment 4 Philippe Rouquier 2008-01-23 19:58:50 UTC
NOTE: I have fedora 8 too.
Comment 5 Denis Leroy 2008-01-24 01:14:40 UTC
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 :-)
Comment 6 Jan Tichavský 2008-01-24 02:10:33 UTC
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
Comment 7 Jan Tichavský 2008-01-24 02:14:19 UTC
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)
Comment 8 Jan Tichavský 2008-01-24 02:14:55 UTC
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...
Comment 9 Philippe Rouquier 2008-01-26 14:06:36 UTC
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.
Comment 10 Denis Leroy 2008-01-26 14:30:42 UTC
> Feel free to reopen it if I miserably failed.

Philippe, I feel the force in you. You will succeed.