Date: Tue, 23 Feb 1999 12:00:43 -0500 (EST) From: tom@tomqnx.com (Tom Torrance at home) To: john@loverso.southborough.ma.us (John Robert LoVerso) Cc: hackers@freebsd.org Subject: Re: Missing files/directories Message-ID: <m10FLCO-000I1oC@TomQNX.tomqnx.com> In-Reply-To: <199902230332.WAA25146@loverso.southborough.ma.us> from John Robert LoVerso at "Feb 22, 1999 10:32:17 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > I just did a scan of the entire /usr/src/sys tree for \"\\.\" > > and \'\\.\' to see what code sections might be affected - mostly > > cache-handling. In quantity, not bad, really. > > Tom, > > I assume by "dot files" you mean things like ".login" or ".profile". > The UNIX kernel does nothing special with these files compared to > files that don't start with a dot. Yes - I was writing them in groups of about 12, to /root (ufs,softupdates) and to /home/tom (nfsv2 mounted). > The special code you'll find in the kernel is for dealing with the > special "." and ".." links in each directory. This is wholey different > from files that begin with ".". Agreed in theory. When I am not writing dot files my systems are apparently rock solid. When I do, I occasionally lose other files or directories that need to be written. They definitely get queued for writing, but disappear from cache before actually getting written to the disk. FOr example, I had copies of all the modified dot files in "dot.xxx" format that I was writing to a directory "/etc/dotfiles". I copied them there and confirmed via "ls" that they were there. 10-15 minutes later, the same ls command would show /etc/dotfiles as entirely empty. Could there be a bug in the code somewhere that ostensibly deals with the "." and ".." files in the cache processing? Is there another theory as to what could cause such behaviour? Regards, Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m10FLCO-000I1oC>