> > Well, it doesn't disappear so much as having its permissions altered,I replied to this post, though only to Otto directly and not to the list - my fault, sorry! So I exchanged a few private emails with Otto, and thanks to Otto's really powerful magic we have a solution for my problem. :-) The cause for the disappearing /dev/null is not SCP or SFTP but mysql on the command line. The bug is described here: http://bugs.mysql.com/bug.php?id=16803 and at the bottom of that thread it seems that they say it's fixed since version 5.0.22, but that's obviously not true. I'm running MySQL 5.0.33 (from snapshots/packages/i386/) and the bug is still there. I had "MYSQL_HISTFILE=/dev/null" in my .profile file because I didn't want to have a file with my mysql history. That works fine as long as you *don't* start mysql as the system user "root". You can start it as normal user with "mysql -u root -p" to log into MySQL as the MySQL user "root" and still everything's working fine. But if you start mysql as sytem user "root" with "mysql -p" or "mysql -u root -p", /dev/null will become a normal file with your latest mysql history inside (or nothing inside if you didn't type any mysql commands except "quit"), *after* you left the mysql shell with "quit". So the solution is: Don't start mysql on the command line as system user "root" or let mysql keep it's history whereever it wants (no "MYSQL_HISTFILE=/dev/null" in .profile). It seems that I always played with mysql while transfering a few files, so I thought it would be a SFTP or SCP issue, but thanks to Otto we know what is really happening. :-) And while testing with mysql Darren's tip to test for changes on /dev/null with a cronjob was very useful: The cronjob found the changes at once. :-) You can avoid the problems easily like described above, but maybe it's even possible that someone fixes MySQL now or maybe adds a warning to the mysql man page. Again thank you very much, Otto and all the others on this great list! I'll keep reading here every day. :-) Tas.