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 592964 - Filenames truncated when importing multisession DVD
Filenames truncated when importing multisession DVD
Status: RESOLVED INCOMPLETE
Product: brasero
Classification: Applications
Component: general
2.26.1
Other Linux
: Normal normal
: 2.26
Assigned To: Brasero maintainer(s)
Brasero maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2009-08-25 01:39 UTC by werdberd
Modified: 2010-04-24 15:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
brasero debug log - multisession disc import filenames bug (8.12 KB, application/x-gzip)
2010-04-24 13:51 UTC, OmegaPhil
Details

Description werdberd 2009-08-25 01:39:36 UTC
I have a multisession DVD that for a few years I've been using to back up pictures that I take.  After recently trying out Ubuntu 9.04 I've discovered that although the filenames displayed are the correct, long versions both while browsing the disc contents in Nautilus as well as in Explorer on a Vista machine, when I try to use Brasero to add more files to the DVD all the filenames for files already on the DVD from previous sessions are capitalized and truncated to thirteen characters with some extra weirdness on the end.  The file extension is also lost.  For example, a file named this_pictures_name_is_too_long.jpg would become THIS_PICTURES;1

This is quite puzzling and is also preventing me from being able to back up pictures on that DVD.  I'm baffled as to why Brasero has a problem with the filenames when Nautilus and Explorer do not.
Comment 1 Philippe Rouquier 2009-09-04 09:12:28 UTC
Thanks for the report.
Could you try to redo an import from that disc but this time, please do a "brasero -g --brasero-media-debug > log 2>&1" in a console and attach the log file to this bug.

I suspect your disc only has joliet extension (not properly supported by brasero as far as names go) and no rock ridge (supported by brasero).
Comment 2 Akhil Laddha 2009-12-28 02:41:49 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!
Comment 3 OmegaPhil 2010-04-24 13:49:53 UTC
(In reply to comment #2)
> Closing this bug report as no further information has been provided. Please
> feel free to reopen this bug if you can provide the information asked for.
> Thanks!

I would like to submit my log for this bug. In my case, I am currently working towards the ability to burn data discs etc like I did under Windows (have recently escaped XP for good), and I have come across this with the first test burn with a multisession disc (the only burning operations I do are multisession data DVD discs, of which I burn hundreds).

uname -a: Linux 2.6.31-20-generic #58-Ubuntu SMP Fri Mar 12 05:23:09 UTC 2010 i686 GNU/Linux

GNOME version: 1:2.22.2~4ubuntu8

Brasero version: 2.28.2-0ubuntu1

The disc in question would have previously been burnt with Nero Express from the Nero 7 Premium Reloaded 7.7.5.1 suite in Windows XP SP2/3.

I'm sure this isn't enough information, so I would be happy to provide anything more that you want.
Comment 4 OmegaPhil 2010-04-24 13:51:22 UTC
Created attachment 159473 [details]
brasero debug log - multisession disc import filenames bug
Comment 5 OmegaPhil 2010-04-24 15:24:02 UTC
To add to this, I'm testing k3b at the moment, and it reports the following on importing a session:

=============================================================================

K3b found session containing Joliet information for long filenames but no Rock Ridge extensions.
The filenames in the imported session will be converted to a restricted character set in the new session. This character set is based on the ISO9660 settings in the K3b project. K3b is not able to display these converted filenames yet.

=============================================================================

So it looks like this incompatibility is widespread.