I may not be phrasing my question correctly, but I'll do my best to explain the symptoms I'm experiencing. First, for context, I'm running an Ubuntu server (no GUI), version 12.04.3 LTS (according the the lsb_release utility). I generally do all of my work in tmux, I connect to the server via Putty, and I use vim for all my text editing.
Now for the symptoms. Since I use tmux, I usually have a few windows open at all times. One of them houses a node server I've been playing around with, and it lives in a subdirectory of my user account's home (specifically,
~/battleship). The server interacts with a webpage I'm also hosting off of the server using nginx, and all the website code lives in
/usr/share/nginx/www/bs (I also keep a separate window open for editing the client source). What happens is that after several hours of leaving the server window idle and untouched, it seems to fall out of sync. I can run
ls and see the files, and I can open them for editing (
vim server.js). When I do that, however, regardless of whether I make changes and save or just quit out instantly, when I run
ls again I see a .server.js.swp file, and none of my changes (if I made any) persist. If I move out of that directory and then back in, it fixes itself - I can open the file and edit it successfully, without leaving behind a .swp when I close it. I mentioned the client source half of things because I've noticed that this doesn't happen in the /www folder (presumably because it's outside of my user account's home directory).
After that wall of text, my question is this: Does anyone know why this is happening, and how to prevent it? I can only imagine there's some way, considering that this isn't the only Linux server I connect to via Putty and use tmux/vim on, and yet it's the only one where this weird behavior happens. Any help would be appreciated.
Note: I tagged this with bash, tmux, and putty because I'm assuming one of them is to blame but I really have no clue which.
Update: This is the output of
cat /proc/mount as requested by Gilles (albeit with my username and the values of
ecryptfs_sig censored, because while I don't actually know what those two things are, they seem encryption-related, and better safe than sorry).
rootfs / rootfs rw 0 0 sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0 udev /dev devtmpfs rw,relatime,size=2008532k,nr_inodes=502133,mode=755 0 0 devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 tmpfs /run tmpfs rw,nosuid,relatime,size=807840k,mode=755 0 0 /dev/disk/by-uuid/2da27263-f079-47ba-90ad-66e4c3a53810 / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0 none /sys/fs/fuse/connections fusectl rw,relatime 0 0 none /sys/kernel/debug debugfs rw,relatime 0 0 none /sys/kernel/security securityfs rw,relatime 0 0 none /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0 none /run/shm tmpfs rw,nosuid,nodev,relatime 0 0 /home/[username]/.Private /home/[username] ecryptfs rw,relatime,ecryptfs_fnek_sig=[censored],ecryptfs_sig=[censored],ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs 0 0
Update 2: Here's the output of
Linux [server-name] 3.5.0-39-generic #60~precise1-Ubuntu SMP Wed Aug 14 15:38:41 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Update 3: I completed a pass of memtest. This is the result of said test. Seems to have completed with no errors, so I'm not sure if it will end up helping with anything. You can also see some hardware details in case that helps in any way.