Date: Tue, 27 Mar 2001 03:38:57 -0600 (CST) From: Ryan Thompson <ryan@sasknow.com> To: Jason Hunt <jhunt@akula.org> Cc: freebsd-questions@freebsd.org Subject: RE: cron Message-ID: <Pine.BSF.4.21.0103270322340.11469-100000@ren.sasknow.com> In-Reply-To: <MPELLGCLCCANIIDHLIHBMEEFCAAA.jhunt@akula.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Jason Hunt wrote to Ryan Thompson: > > The temp file moved or was deleted then re-linked. Did you > > change your default editor? Maybe your editor (or invocation > > thereof) is renaming the temp file (and/or you enabled > > backups in your editor). > > No nothing like this. I didn't change editors - still vi. Before > this problem accured my server had power lost to it and the UPS failed. Hmm.. Because UNIX machines tend to have long uptimes (usually dependent only on sysadmin ;-) funny things can creep up after reboots. Why don't you try the following (choose a name "somefile" that does not exist): $ echo "Foo" > somefile $ ls -li somefile /* Note the inode number */ $ vi somefile /* Edit and save changes */ $ ls -li somefile /* Note the inode number */ Script started on Tue Mar 27 03:29:02 2001 ryan@ren $ echo "Foo" >somefile ryan@ren $ ls -li somefile 73306 -rw-rw-r-- 1 ryan staff 4 Mar 27 03:29 somefile ryan@ren $ vi somefile << typical editing session >> :wq! somefile: 3 lines, 11 characters ryan@ren $ ls -li somefile 73306 -rw-rw-r-- 1 ryan staff 11 Mar 27 03:29 somefile ryan@ren $ exit Script done on Tue Mar 27 03:29:37 2001 If the inode numbers are the same (eg., 73306), you are accessing the same file, and all is good. If the inode numbers differ before and after editing, it means vi actually unlinked the original file and re-created a new file. Depending on your setup, version/vendor of vi, this may be the case, although it is somewhat rare in practice. Other than that, perhaps the directory entry underneath is hosed in some weird way. Kill init and completely wipe your tmp directory (rm -Rf /tmp) and re-create it with the appropriate permissions (mkdir -m 4777 /tmp). > So when I got back to the machine, I was forced to run fsck > manually. I believe this has something to do with it, but still > not sure what I need to do in order to fix this program? I reran > fsck, but no luck. If you want to do it in the safest way possible (You may fix errors with different methods, but they may recur if the filesystems are mounted writable): 1 Go to single user mode (issue the command "shutdown now" as root) 2 Choose a shell 3 When greeted with the single user # prompt, unmount your filesystems (or downgrade them to read-only if necessary). 4 run fsck -p (preen mode) 5 Bring the system back up -- Ryan Thompson <ryan@sasknow.com> Network Administrator, Accounts SaskNow Technologies - http://www.sasknow.com #106-380 3120 8th St E - Saskatoon, SK - S7H 0W2 Tel: 306-664-3600 Fax: 306-664-1161 Saskatoon Toll-Free: 877-727-5669 (877-SASKNOW) North America To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0103270322340.11469-100000>