UTF-8 filesystem hosed by banshee

[EricDHH]

Binary package hint: banshee

Karmic amd64

If u import music with umlauts, apostrophs into their tags and banshee imports with "move and copy to folders" a proper utf-8 filesystem gets hosed. Test with: Clannad/Cran Üll, Laith Al Deen
The files and folders become ?????names and banshee itself could not read the files anymore. Renaming and delete from gui tools are denied too, now you have zombies in the filesystem that break some further tools. Fslint can find these illegal files and folders, but is unable to repair them.

Suggesttion: Banshee should check for illegal chars for the used filesystem.

Severity critical

ProblemType: Bug
Architecture: amd64
Date: Sun Dec 20 11:13:00 2009
DistroRelease: Ubuntu 9.10
ExecutablePath: /usr/bin/yelp
NonfreeKernelModules: nvidia
Package: yelp 2.28.0-0ubuntu2
ProcEnviron:
 LANGUAGE=de_DE@euro
 LANG=de_DE@euro
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-17.54-genusername
SourcePackage: yelp
Uname: Linux 2.6.31-17-generic x86_64

[Chow Loong Jin (hyperair)]

As far as I know, Banshee handles UTF-8 perfectly fine, at least where Japanese and Chinese characters are concerned. Perhaps your filesystem isn't supporting them properly? What filesystem are you using? And if a userspace application is able to create files that are not deletable or renamable, wouldn't that imply that the filesystem itself is the one that's buggy?

[EricDHH (ericdhh)]

The filesystem was a ext2 utf-8 on a nas that is shared with cifs to the banshee machine. Lots of files get C64 graphic chars, questionmarks and (ungültige Kodierung) extensions to their names. Cifs was mounted with defaults on ubuntu, maybe there is some kind of conversion? This is the smb.conf from the nas

[ global ]
interfaces = egiga0
unix charset = UTF8
workgroup = WORKGROUP
netbios name = Tuxstore
server string = Files and Sound
hosts allow =
hosts deny =
security = SHARE
encrypt passwords = yes
max log size = 0

[Chow Loong Jin (hyperair)]

On Monday 28,December,2009 12:36 PM, EricW@Hamburg wrote:
> The filesystem was a ext2 utf-8 on a nas that is shared with cifs to the
> banshee machine. Lots of files get C64 graphic chars, questionmarks and
> (ungültige Kodierung) extensions to their names. Cifs was mounted with
> defaults on ubuntu, maybe there is some kind of conversion? This is the
> smb.conf from the nas
>
> [ global ]
> interfaces = egiga0
> unix charset = UTF8
> workgroup = WORKGROUP
> netbios name = Tuxstore
> server string = Files and Sound
> hosts allow =
> hosts deny =
> security = SHARE
> encrypt passwords = yes
> max log size = 0
>
I'm not very familiar with cifs mounted shares, but could you try creating a
file with the correct name, encoded in UTF-8 on some local filesystem, then
copying it over to the CIFS share and seeing if that works? I find it quite hard
to believe that Banshee is at fault here.

--
Kind regards,
Chow Loong Jin (GPG: 0x8F02A411)
Ubuntu Contributing Developer

[EricDHH (ericdhh)]

Tested with local utf-8 was okay, found a solution to get nfs to my nas device. Now the encoding is well, so this seems to bee a bug in cifs shares and encoding.

Bug can be closed
Thanks
Eric

[Chow Loong Jin (hyperair)]

On Wednesday 30,December,2009 01:10 AM, EricW@Hamburg wrote:
> Tested with local utf-8 was okay, found a solution to get nfs to my nas
> device. Now the encoding is well, so this seems to bee a bug in cifs
> shares and encoding.
>
> Bug can be closed

Closing bug for Banshee, thanks for your time.
  affects ubuntu/banshee
  status invalid

Considering this is a CIFS bug, I'm marking this as affecting linux (I think
that's where CIFS resides).
  affects ubuntu/linux
  status new

--
Kind regards,
Chow Loong Jin (GPG: 0x8F02A411)
Ubuntu Contributing Developer

[Brad Figg (brad-figg)]

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.