Re: [patch] [bug 432510] samba filename encoding on none UTF-8 locales
- From: Takao Fujiwara - Tokyo S/W Center <Takao Fujiwara Sun COM>
- To: Alexander Larsson <alexl redhat com>
- Cc: nautilus-list gnome org
- Subject: Re: [patch] [bug 432510] samba filename encoding on none UTF-8 locales
- Date: Fri, 27 Jul 2007 20:12:39 +0900
Alexander Larsson wrote:
> On Wed, 2007-07-25 at 10:27 +0900, Takao Fujiwara - Tokyo S/W Center
> wrote:
>
>>Hi,
>>
>>Are there acceptable solutoins?
>>I'ld like to fix this problem asap.
>
>
> I don't think any solution is really right at this time. Neither
> solution is ideal, and we add hacks that are visible to the user (env
> vars) that we have to keep supporting in the future, and hacks that
> doesn't fully fix the issue. And all this is for something that is
> scheduled for replacement.
Thanks for your reply. Now I agreed with your point and also I feel it's quite difficult to fix this problem fully in the current nautilus and gnome-vfs without gvfs.
However my point is a slightly different from yours. I think gvfs is a new feature and currently gnome-vfs has this bug. I completely agree gvfs will resolve almost problems against gnome-vfs but e.g. there are no solutions when I want any fixes in three months. I haven't thought to provide full supports for samba of equal gvfs at the moment but I'm asked to fix the critical problems with samba.
If I think the previous version of GNOME, e.g. 2.6, it may be difficult to use gvfs since backports something will be needed.
But I understood it's not good for you to hack the visible env values because those env values won't be used once gvfs is available.
I don't find which resolutions I should take.
What do you think this kind of patches are applied by each vendors and the vendors will maintain the patches by themselves until gvfs is available but the patches are not integrated in nautilus/gnome-vfs head and/or branch? Are there any concerns/suggestions in your side?
When is the target to release gvfs?
>
> Btw. Your gnome-vfs api doesn't seem right approach either. Filenames
> and URIs are what they are, a byte-string that represent the identifier
> of the file. We can't convert it to or from anything and expect things
> to keep working. That will break when filenames are not properly encoded
> or when conversion looses data. The correct API is to have a proper
> split in the API about "file identifier" and "file display name". This
> is what gvfs does. You keep around both, one to do operations on the
> file, and the other to display to the user.
I also think the new member "file display name" is needed to fix this problem fully but I think it would be a limitation of gnome-vfs.
>
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]