[Bug 289255] New: Desktop to Path symlink handling, option to choose [absolute] or [relative]

[Jose Da Silva]

https://bugs.kde.org/show_bug.cgi?id=289255

           Summary: Desktop to Path symlink handling, option to choose
                    [absolute] or [relative]
           Product: systemsettings
           Version: 1.0
          Platform: Mageia RPMs
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: wishlist
          Priority: NOR
         Component: kcm_desktoppath
        AssignedTo: unassigned-bugs at kde.org
        ReportedBy: Digital at JoesCat.com


Version:           1.0 (using KDE 4.7.3) 
OS:                Linux

In the Mageia Forums, it came to attention that path selection appears
different when upgrading from Mandriva 2010.2 (using KDE 4.3) to Mageia 1
(using KDE 4.6.5). I just checked with Mageia 2 Alpha1 (using KDE 4.7.3) and
see this still exists.

Problem:
When you open an application, such as Kwrite, Okular, Ksnapshot, Gwenview, if
your designated path is a symlink to another location, instead of following the
symlink as defined, we begin with the absolute translated real path. In prior
versions of KDE (4.3) you would normally follow the symlink path, but now with
KDE 4.6.5,4.7.3 we are given the real path.
You can follow the discussion details here:
https://forums.mageia.org/en/viewtopic.php?f=8&t=1578
title "make application go to the symlink"

Wishlist Question:
Would it be possible to add a feature into kcmshell4 desktopath to allow users
to follow the relative or the absolute path. It is understood some people come
from a Windows background and may prefer or be used to an absolute path, while
users more accustomed to a unix/linux/bsd background are more used to a symlink
followed path. Having this option available would allow users to choose there
preferred option choice if the described path happens to be a symlink to
another location.

Reproducible: Always

Steps to Reproduce:
1) In case you cannot replicate this under a simpler setup, then it is probably
best to begin with 2 different partition compiled with different file
formatting, for example "/home/user" is located in "/dev/sda1" and formatted as
"reiserFS", partition "/dev/sda5" is "/" (not important, but let's say ext4),
and another partition "/dev/sda6" is formatted as xfs and holds "/mnt/temp".

2) In /mnt/temp, now create another directory, temp2, and give it read/write
permissions so that user can write in it... chmod 777 /mnt/temp/temp2

3) In user's home directory, create a symlink.
cd ~
ln -s /mnt/temp/temp2 /home/user/xyz

4) Start KDE's System settings and go to Account Details, and convert the
existing paths to use the symlink instead. Examples:
Document Paths: /home/user/xyz/
Pictures Paths: /home/user/xyz/
Apply the fix, do not move documents to new location.

5) Run a program. Okular. Select File->Open
expected path is /home/user/xyz but the given path shows /mnt/temp/temp2

6) Try a few other programs, Ksnapshot, Kwrite ...

Actual Results:  
Open or Save file default location points to the resolved path of
/mnt/temp/temp2

Expected Results:  
Was hoping to see the symlink path since the path written in desktopath was
/home/user/xyz.

There are some KDE bugs and wishes (around KDE 4.3) where this began gradually
changing from the stated method to the resolved method.
http://forum.kde.org/viewtopic.php?f=22&t=84150
http://forum.kde.org/brainstorm.php#idea84173_page1
and eventually by version KDE 4.7.3 (approaching 4.8) we begin to see a fair
bit of the resulting changes.
http://trueg.wordpress.com/2011/12/07/symbolic-links-in-nepomuk-a-solution/

As mentioned up above... this came about as something of interest in
https://forums.mageia.org/en/viewtopic.php?f=8&t=1578

this problem could be worked-around by providing a different path, like
/home/user but maybe it is worth adding an option or selection toggle for these
exceptions when users use a symlink as their chosen path.

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.