Bug 117524

I agree, and when I try to play a video in "system:/home/" it has to copy the whole video into "file:///tmp/kde-chris/" before opening the video with kaffeine. It is very slow and I hope this is not the correct behaviour :)

I agree!
KIO Slaves in KDE 3.5.0 seem incomplete and broken!!

In KDE 3.4.x they were a lot more usable.

PLEASE FIX THAT !!!

Still nothing...?

*** This bug has been confirmed by popular vote. ***

Furthermore when trying to edit file permissions (properties) on system:/home I can't see any ACL related setting, "Meta Info" and "Share" tabs. Same with system:/users/me and any other.

Confirmed, and I totally agree too.
Apart from giving a nice rendering in the address bar (homogenous system:/foo thing), nothing is really improved, and more than that, lots of issues are added.
The old way to work, while system:/ was linking to £HOME instead of system:/home was way better, and bugfree...

Similar problems with media:  Lots of apps can't handle this and need
special treatment just to file out there the file is on the local
FS :(

Achim

Some more problems:
from https://launchpad.net/distros/ubuntu/+source/kdebase/+bug/32159/

"1 - system:// protocol can not be undertand by GTK apps at all. If you "Opern with" GIMP system://home/file.png any image you will see "no such file" error.

2 - it can not be understand corrently with KDE apps too. If you will enter folder with many picture you would be able to open just one and will not be able to scroll to next image. It will also be hard to open large AVI movie, because KDE will copy it first to /tmp which is redundant and long to wait."

Re: comment #8
1. KIO is a technology specific to KDE, and therefore no GTK app can support it.

Re: comment #8
indeed, KIO works only in KDE. But it is one of the goals of KDE to work with other applications as well as with native ones. And there are methods which can translate KIO-specific URLs to generic ones or absolute paths, if possible and necessary. And within the local file system this translation should always be possible, just the integration is missing. konqueror just has to check if an application is a KDE-one or not, and in doubt only pass the translated URL to the application. Nobody requests the impossible, but all of the mentioned 'little' problems could/should be solved within the KDE-3.5 series, which will last at least one more year. 
there are places were users will hit by chance upon the "system:/" URLs, and if once inside, they will stay in this hierarchy, just discovering that nothing is working as it used to be. and for the normal user the source of the problems as well as the internal difference between "file:/" and "system:/" is not obvious.

Please also look at:
Bug 123783   settings:/ is missing in system:/
Bug 123784   it is not possible to access / from system:/ anymore
Bug 123786   since KDE 3.5(.1) it isn't possible anymore to have a picture/sound preview in directories accessed through system:/
Bug 124110   kio system wish: user shall be able to decide and choose which modules are shown in system:/

This one is related too :
#117516

KDE's new device hotplug technology opens the content of a camera with the kioslave system:/. That prevents the user from scrolling through the pictures on the camera (with *KDE* programs like kuickshow and gwenview) because the current picture is being copied to the tmp-directory. Instead you now scroll through pictures in your tmp-directory... :( Therefore the whole device dialog is unusable for all you can do when you want to work with the files on your usb device is hitting cancel, do nothing - and then open the "system folder" (which confusingly does *not* use system:/ as its name says) of it via the context menu. When I look at the content of a cdrom (and I have many picture CDs), browsing through them with the standard KDE picture viewers also is not possible.

And those kioslaves should not cover real addresses. Looking at the content of a cdrom with konqueror (via the automatic "hello, I have found a cdrom" dialog) the address shown in the address bar of konqueror is system:/media/hdc/ - when I open a konsole (F4) I end up in /media/cdrom0 - that's confusing. So I have two different addresses for one place. And if I don't open a terminal but just want to have the real folder to browse the files I cannot just delete the system:/ in the address bar because the folder is *not* /media/hdc but (what I don't know without opening a terminal) /media/cdrom0. To make it even more confusing erasing the system:/ part in the address bar works using a usb stick (system:/media/sda1 is /media/sda1).

Even more confusing (and usuable) is the terminal emulator of konqueror. Instead of following the behaviour of the terminal it (opened in a kioslave directory) does *not* show the current directory but always opens in my home directory.  

The usage of system:/ really messes up simple working processes and unnecessarily consumes a lot of internal bandwidth (cpu, memory, hard disk space).

At least it would be nice if those system:/ addresses were redirected to real addresses if the target program is a non-KDE program like e.g. the very common Gimp and if action is required to more than one file (e.g. viewing pictures with gwenview/kuickshow). And the automatic media dialog should also offer a "open system folder" to bypass the system:/ kioslave to enable browsing  through files with a picture viewer (no copying to tmp directories please). Or maybe someone has managed to add an option like that to device dialog and can tell me? 

You can workaround that by enabling the preview of media kio-slave files under the konqueror configuration.

system:/ no longer exists - see http://commit-digest.org/issues/2007-07-08/moreinfo/684518
closing.