Bug 189837

Summary: Application data directory on CIFS share should be supported or ignored
Product: [I don't know] kde Reporter: Stefan Mayrhofer <mayly>
Component: generalAssignee: Patrick Spendrin <ps_ml>
Status: RESOLVED FIXED    
Severity: normal CC: nate, ps_ml
Priority: NOR    
Version First Reported In: 4.2.2   
Target Milestone: ---   
Platform: Microsoft Windows   
OS: Microsoft Windows   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Stefan Mayrhofer 2009-04-16 21:36:32 UTC
Version:            (using KDE 4.2.2)
Compiler:          MSVC 
OS:                MS Windows
Installed from:    MS Windows

There is an issue when using roaming profiles. On the test installation the "Application data" directory is given by an CIFS share. While "Documents and Settings" are locally. 4.2.1 just placed the ".kde" directory into the latter one while 4.2.2 uses "Application data" which now breaks KDE on this installation because CIFS shares are not supported.

kbuildsycoca4.exe says: "trying to create local folder //atlas: Invalid argument"

By using the local "Application data" directory in "Local Settings" this should work for all installations. Later, when CIFS support in KDE is working, the regular "Application data" should be used.

BTW, I am lazy to file a new bug for this but when you are doing this, you could rename ".kde" to "KDE" -- two birds one stone.
Comment 1 Andrew Crouthamel 2018-11-02 23:06:42 UTC
Dear Bug Submitter,

This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond.

Thank you for helping us make KDE software even better for everyone!
Comment 2 Andrew Crouthamel 2018-11-16 05:23:59 UTC
Dear Bug Submitter,

This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version?

Thank you for helping us make KDE software even better for everyone!
Comment 3 Nate Graham 2020-09-28 23:37:17 UTC
No response; assuming it was fixed since then.