tags 612675 pending confirmed
owner 612675 !
thanks
Hello,
On šeštadienis 14 Gegužė 2011 14:44:48 Ibragimov Rinat wrote:
Well, ok, but that still does not explain why you cast one check to
(unsigned char) leaving others untouched. QByteArray::operator[] also
returns a _signed_ char. So
Processing commands for cont...@bugs.debian.org:
tags 612675 pending confirmed
Bug #612675 [libkio5] libkio5: KTar class have broken UTF-8 support (longlink)
Added tag(s) confirmed and pending.
owner 612675 !
Bug #612675 [libkio5] libkio5: KTar class have broken UTF-8 support (longlink)
Owner
Well, ok, but that still does not explain why you cast one check to
(unsigned char) leaving others untouched. QByteArray::operator[] also returns
a _signed_ char. So what makes you think those chars will always be = 127 ?
Um, yes, you're right. I missed code that reads tar files. There
Hello,
On pirmadienis 09 Gegužė 2011 13:24:51 Ibragimov Rinat wrote:
Can you point to some of those checks? I've looked through the code
again and found nothing related to QString. There are only some of
them related to QByteArray.
But why do you think QByteArray checks are not
What I'm concerned about is that your patch may not be complete. There are
more similar checks in ktar.cpp. As I absolutely have no idea how tar works,
this will take time to handle properly (or hopefully upstream responds in the
meantime). Thanks for forwarding the bug.
Can you point to
Hello,
On pirmadienis 09 Gegužė 2011 11:19:23 Ibragimov Rinat wrote:
What I'm concerned about is that your patch may not be complete. There
are more similar checks in ktar.cpp. As I absolutely have no idea how
tar works, this will take time to handle properly (or hopefully upstream
Can you point to some of those checks? I've looked through the code again
and found nothing related to QString. There are only some of them related
to QByteArray.
But why do you think QByteArray checks are not affected?
Because QByteArray is intended to store raw bytes [1], while QString
Hello,
On trečiadienis 04 Gegužė 2011 11:40:43 Ibragimov Rinat wrote:
This though is not totally clear to me. On the major architectures,
char is signed, so I would assume that a chksum error in this area
should have hit a lot of people already? Given that int is signed by
default I
Hi!
First of all, sorry for late response. The bug got overlooked in the
aftermath of the squeeze release, people were quite busy here.
* Rinat ibragimovri...@mail.ru [2011-02-09 23:16:22 CET]:
First, tar archives have to use longlink trick to
store names longer than 100 bytes. KTar
This though is not totally clear to me. On the major architectures,
char is signed, so I would assume that a chksum error in this area
should have hit a lot of people already? Given that int is signed by
default I wonder if this is the proper approach and it shouldn't rather
be cast to signed
Package: libkio5
Version: 4:4.4.5-3.1
Severity: grave
Tags: patch
Justification: causes non-serious data loss
I tried to create tar by KBackup program and found
truncated names of my files in .tar. KBackup uses
KTar class for writing tar files and that class
have broken UTF-8 support, it seems.
11 matches
Mail list logo
