Problems with KDE_stat on systems where the default locale is not utf-8

Christian Ehrlicher Ch.Ehrlicher at gmx.de
Mon Dec 1 11:19:33 GMT 2008


> Von: Thiago Macieira <thiago at kde.org>
> Thiago Macieira wrote:
> >Ralf Habacker wrote:
> >>Christian Ehrlicher schrieb:
> >>> Thiago Macieira schrieb:
> >>>> On Thursday 20 November 2008 09:11:22 Christian Ehrlicher wrote:
> >>>>>> The Qt API will. Or, alternatively, the Win32 API will (the *W
> >>>>>> functions).
> >>>>>
> >>>>> How fast is QFileInfo in Qt4.5? If it's too slow I'm still for a
> >>>>> new small
> >>>>> wrapper class for local files inside KDE to handle stat() and
> >>>>> others. Adding ifdefs everywhere isn't a nice solution at all.
> >>>>
> >>>> No improvement.
> >>>>
> >>>> The problem is systematic and can't be improved. It can only be made
> >>>> faster by ditching the file engine support we added in older
> >>>> versions of Qt. That is, only for Qt 5.
> >>>
> >>> I would like to add some new functions to kde_file.h - if possible
> >>> before 4.2 so we can handle non-encodeable filenames on windows.
> >>>
> >>> namespace KDE
> >>> {
> >>>   KDECORE_EXPORT int chmod(const QString &path, mode_t mode);
> >>>   KDECORE_EXPORT int link(const QString &in, const QString &out);
> >>>   KDECORE_EXPORT int lstat(const QString &path, KDE_struct_stat
> >>> *buf); KDECORE_EXPORT int mkdir(const QString &pathname, mode_t
> >>> mode); KDECORE_EXPORT int open(const QString &pathname, int flags);
> >>> KDECORE_EXPORT int open(const QString &pathname, int flags, mode_t
> >>> mode);
> >>>   KDECORE_EXPORT int rmdir(const QString &pathname);
> >>>   KDECORE_EXPORT int remove(const QString &pathname);
> >>>   KDECORE_EXPORT int rename(const QString &in, const QString &out);
> >>>   KDECORE_EXPORT int stat(const QString &path, KDE_struct_stat *buf);
> >>>   KDECORE_EXPORT int symlink(const QString &in, const QString &out);
> >>>   KDECORE_EXPORT int unlink(const QString &pathname);
> >>>   KDECORE_EXPORT int utime(const QString &filename, struct utimbuf
> >>> *buf); };
> >>> Maybe I forgot some
> >>
> >>close(), read(), write(), lseek(),creat()
> >
> >Yes for creat, but we should use the three-argument open instead.
> >
> >As for the others, they do not take the file name, only a file
> > descriptor. So there's no need to overload with QString.
> 
> It has just occurred to me: what's your point with this?
> 
> Do you want people to write code like?
> 
> #ifdef Q_OS_WIN
> 	int fd = open(filename, O_RDONLY);
> #else
> 	int fd = open(QFile::encodeName(filename), O_RDONLY);
> #endif
> 
> Why should we have all of those #ifdefs everywhere in KDE code?
> 
No, I want to avoid this but forgot about the encoding problems on unix.

> The QString overloads are not enough for the Unix side, so they can't be 
> used. At the same side, the const char* are not enough for the Windows 
> side.
> 
> If we're going to do anything about this, how about using the preferred 
> final solution: QUrl/KUrl ? That's the only thing that meets the needs of 
> both sides. (Not KUrl yet)
> 
Ok, then s/QString/QUrl/g in all functions above - correct?

If you don't want to have it in 4.2 I can wait for 4.3 but it would be nice to get this for 4.2 :)


Christian




More information about the kde-core-devel mailing list