[Spice-devel] [spice-gtk v1] file-xfer: Fix bad filename encoding

[Victor Toso]

Hi,

On Wed, Apr 12, 2017 at 11:43:14AM -0400, Frediano Ziglio wrote:
> >
> > On Wed, Apr 12, 2017 at 10:46:58AM -0400, Frediano Ziglio wrote:
> > > >
> > > > On Wed, Apr 12, 2017 at 03:55:04PM +0200, Victor Toso wrote:
> > > > > I'm not specialist on possible problems but although ascii is
> > > > > compatible
> > > > > with utf8 it might become a problem to not have a standard well defined
> > > > > in the future although Marc-André said it should be UTF-8.
> > > >
> > > > If you mandate UTF-8 in the protocol, you probably cause a regression if
> > > > your client has an iso8859-1 filename, and you dnd that to a VM where
> > > > you also expect the iso8859-1 filename. In this day and age, this is
> > > > just a corner case, but I'm not sure mandating UTF8 conversion of
> > > > filenames before dnd'ing them is not going to cause issue either.
> > > >
> > > > Christophe
> > > >
> > >
> > > That's why another alternative I wrote was to get the _byte_string of
> > > normal name.
> > > Note however that passing the binary is not possible on Windows
> > > as utf16 is a completely different beast (maybe glib does already
> > > some transformation at least to make it C compatible).
> > > Yes, invalid encoding is the same stuff that worry me, on the
> > > other hand current code seems broken with the utf8 which is the
> > > default on most Unix now.
> >
> > My understanding is that we used to be using g_file_get_basename,
> > switching  back to it would give us an encoding-less byte array,
> > which probably has its share of corner cases, but worked well enough so
> > far.
> >
> > Christophe
> >
>
> I remember I did something with file names in a long past.. but maybe
> was Windows agent.

ETOOMUCHCODE

> By the way, the change is in "file-xfer: introduce functions to init task async"
> (4647ac9a2a72c98b6841180ccf5f8dfa61c6cce8) but I cannot find any specific
> note about this basename -> display name change.
> No idea why was done.

I introduced _init_task_async() and its _init_task_finish() there so no
obvious reasons for the function change that introduced this regression.
My memory is not so good either.

The callback functions needs to send the VD_AGENT_FILE_XFER_START
message which needs the file name and size. As
spice_file_transfer_task_init_task_finish() returns a GFileInfo* I might
have thought it would be better to use it for both things.

Of course, I did not take enough stuff in consideration!

Cheers,
        toso
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20170413/2d51ec60/attachment.sig>