Version: 1.0.2 (using KDE 4.0.5) Installed from: SuSE RPMs Compiler: gcc 4.2.1 OS: Linux KDE does not start, if the home directory is a CIFS mount. I use samba-3.0.26a-3.7 (Server) and cifs-mount-3.0.26a-3.7 (Client) on Linux (openSUSE 10.3). cifs-mount should provide enough UNIX compatibility to run any Unix application (including symlinks, hard links etc.). There are problems with lockfiles for kconf_update in the X session logs: WARNING: Problem deleting stale lockfile /home/bv/.kde4/share/config/kconf_updaterc.lock WARNING: Problem deleting stale lockfile /home/bv/.kde4/share/config/kconf_updaterc.lock WARNING: Problem deleting stale lockfile /home/bv/.kde4/share/config/kconf_updaterc.lock [...] (endless loop) The problem already exists on KDE 3.x. But I also find the problem on KDE 4.0.5. The source code already contains some work arounds for the file locking problem for SMBFS (a predecessor of CIFS) shares: http://lxr.kde.org/source/KDE/kdelibs/kdecore/io/klockfile_unix.cpp: 225 // SMBFS supports hardlinks by copying the file, as a result the above test will always fail 226 if (linkCountSupport) 227 { 228 linkCountSupport = testLinkCountSupport(tmpFile); 229 } 230 231 if (!linkCountSupport && 232 (KDE_lstat(lckFile, &st_buf2) == 0) && st_buf == st_buf2) 233 { 234 // Without support for link counts we will have a little race condition 235 qWarning("WARNING: deleting stale lockfile %s", lckFile.data()); 236 ::unlink(lckFile); 237 ::unlink(tmpFile); 238 return KLockFile::LockOK; 239 } 240 241 // Failed to delete stale lock file 242 qWarning("WARNING: Problem deleting stale lockfile %s", lckFile.data()); 243 ::unlink(tmpFile); 244 return KLockFile::LockFail; linkCountSupport is false on in my setup. But the second check (KDE_lstat(lckFile, &st_buf2) == 0) && st_buf == st_buf2 is also false because the st_link fields are not equal. As the result, the error message "WARNING: Problem deleting stale lockfile %s" is displayed. Without a fix for this problem the KDE start script runs in an infinite loop, because kconf_update does not terminate. Probably also single KDE applications may fail on CIFS, because some of them use the KLockFile class, which is broken for CIFS.
Here are some additional notes for linux-cifs support. My testing is still based on samba-3.0.26a-3.7 (Server) and cifs-mount-3.0.26a-3.7 (Client) on Linux (openSUSE 10.3). Other setups (for instance Windows server) may produce other results. - hard links could be created on the remote CIFS site # ln file1 link1 - on the server site the newly created links are really hard links # ls -li file1 link1 48843 -rw-r--r-- 2 bv bv 0 29. Jun 12:34 file1 48843 -rw-r--r-- 2 bv bv 0 29. Jun 12:34 link1 - on the server site "file1" and "link1" both have the same link count, but not the same inode number. # ls -li file1 link1 43502 -rw-r--r-- 2 bv bv 0 29. Jun 12:34 file1 43503 -rw-r--r-- 2 bv bv 0 29. Jun 12:34 link1 - The inode numbers are not based on the server inode numbers. Other each new mount the inode numbers may change on the client site: # cd / # sudo umount /home # sudo mount -t cifs //chemnitz/bv /home/bv -o username=bv Password: # cd # ls -li file1 link1 47570 -rw-r--r-- 2 bv bv 0 29. Jun 12:34 file1 47575 -rw-r--r-- 2 bv bv 0 29. Jun 12:34 link1 This behavior results in the fact that 231 if (!linkCountSupport && 232 (KDE_lstat(lckFile, &st_buf2) == 0) && st_buf == st_buf2) is false on CIFS, because st_buf is not st_buf2 (the inode numbers do not match).
I wish I had seen this investigation before spending time on 156759... *** This bug has been marked as a duplicate of bug 156759 ***