Hi Tim,

It's strange because i can see in the .nfs** file : information from startkde.

Like this :

In .nfs00000000000e0495000016f4 " Xsession: X session started for XXXXX at jeudi 7 novembre 2013, 09:01:38 (UTC+0100) /usr/bin/xmodmap: unable to open file '/usr/share/apps/kxkb/ubuntu.xmodmap' for reading /usr/bin/xmodmap: 1 error encountered, aborting. [startkde] Starting startkde. [startkde] This script is /usr/bin/startkde4 [startkde] TDE version is 3.5.13.1 [startkde] TDE base directory is /opt/trinity [startkde] KDEHOME is not set. [startkde] Set KDEHOME to /home/XXXX/.trinity. [startkde] Setting KDEROOTHOME to /root/.trinity. [startkde] KDEDIR: /opt/trinity [startkde] KDEDIRS: [startkde] Starting Trinity... kdeinit: Launched DCOPServer, pid = 30319 result = 0 kdeinit: Launched KLauncher, pid = 30325 result = 0 kdeinit: opened connection to :1114.0 kdeinit: Launched KDED, pid = 30326 result = 0 kdeinit: Got EXT_EXEC 'kbuildsycoca' from launcher. kbuildsycoca running... Reusing existing ksycoca kdeinit: PID 30328 terminated. kdeinit: Got EXEC_NEW 'kconf_update' from launcher. kdeinit: PID 30329 terminated. kdeinit: PID 30326 terminated. reading '/home/XXXX/.kompmgr.pid' as kompmgr pidfile

[startkde] TDE_FULL_SESSION: true [startkde] KDE_SESSION_UID: 81206 kdeinit: Shutting down running client. kdeinit: Killing kdeinit/klauncher.

..... "

For .DCOP file, i have some : dcopserver [kdeinit] --nosid --suicide process

Thanks for your help.

Sincerely,

Jean

2013/11/8 Timothy Pearson kb9vqf@pearsoncomputing.net

...

Hello,

I use FreeNX to connect to a debian server with TDE.

I have some files in my home, not delete when the session stop :

$HOME/.nfs* $HOME/.DCOP*

And sometimes i have some /tmp/.X* and /tmp/.X11-unix/X* not delete when

i

...

deconnect.

Have you some informations about this ?

Thanks for your help.

Sincerely,

Jean

-- MILOT Jean Tél. : 0659514624 milot.jean@gmail.com

The .nfs files are NFS lock files. The .DCOP files are created by the TDE dcopserver, and in fact the dcopserver may still be running on your system (try "ps aux | grep dcop" to check).

Tim

---

To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting

On 8 Nov 2013, Timothy Pearson verbalised:

...

$HOME/.nfs* $HOME/.DCOP*

[...]

The .nfs files are NFS lock files.

The .nfs files are NFS 'silly-delete' files. In Unixlike operating systems, it is expected behaviour that you can delete a file you have open and continue using it -- but an NFS server, being stateless, has no idea what files its clients have open. So as a hack around this, when an NFS client gets asked to delete a file it has open, it requests that the server rename it to .nfs{random junk} instead, then sends a delete for that when it is closed. This is a hack and clearly cannot work in all cases (i.e. a process on one client holds a file open, and a process on another client deletes it) -- but in practice it works well enough to be getting on with, except if the client crashes. Then it cannot ever send the delete request for the silly-delete files, and they build up.

Because they are the wreckage of old files (often temporary files) that were deleted but not closed, it is normal for them to contain actual, real, useful data.