The BitKeeper source tree looks like
BitKeeper/ SCCS/ doc/ man/ src/
I have a repository where it looks like
src/ BitKeeper/ PENDING/ RELEASE-NOTES SCCS/ doc/ man/ src/
That first src/ is actually " src/" and it has some rather strange behaviour.
It's a different directory inode than "src/" but if I create a file in " src/"
it shows up in "src/" and vice versa.
Hey, neato, it gets weirder. I went to go run an example and now most of
the files in " src/" are gone, most but not all.
I'm merrily backing up this disk while I can but if this rings any bells
someone let me know. Thanks.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Fri, Nov 07, 2003 at 10:33:41PM -0800, Larry McVoy wrote:
> The BitKeeper source tree looks like
>
> BitKeeper/ SCCS/ doc/ man/ src/
>
> I have a repository where it looks like
>
> src/ BitKeeper/ PENDING/ RELEASE-NOTES SCCS/ doc/ man/ src/
>
> That first src/ is actually " src/" and it has some rather strange behaviour.
> It's a different directory inode than "src/" but if I create a file in " src/"
> it shows up in "src/" and vice versa.
>
> Hey, neato, it gets weirder. I went to go run an example and now most of
> the files in " src/" are gone, most but not all.
Sounds like there is a two directory entries with the same name in the
same directory. This can cuase severe confusion since the kernel
assumes that this will never happen. Depending on which one gets
found first, and what is cached in the dentry cache, you'll get one
inode or the other.
E2fsck doesn't normally notice these sorts of inconsistencies, since
it takes too much time and memory to look for duplicate entries. If
you optimize directories using "e2fsck -fD", it will find and offer to
rename directory entires with a duplicated name.
If you notice the problem, you can also go in directly with debugfs
and rename the errant directory entry directly.
- Ted
On Sat, Nov 08, 2003 at 11:44:10AM -0500, Theodore Ts'o wrote:
> If you notice the problem, you can also go in directly with debugfs
> and rename the errant directory entry directly.
Or you can reinstall :) I gave up and did so, Al got me nervous talking
about rootkits and breakins and such. If it happens agains I'll swap disk
drives if someone wants to poke at it.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sat, 8 Nov 2003, Theodore Ts'o wrote:
> Sounds like there is a two directory entries with the same name in the
> same directory. This can cuase severe confusion since the kernel
> assumes that this will never happen. Depending on which one gets
> found first, and what is cached in the dentry cache, you'll get one
> inode or the other.
It seems they've two different names "src" and " src" and ext2_match()
should not be fooled by the space. If this is the drive that has been
hacked, I'd rather go for a full cleanup.
- Davide
Hi!
> > Hey, neato, it gets weirder. I went to go run an example and now most of
> > the files in " src/" are gone, most but not all.
>
> Sounds like there is a two directory entries with the same name in the
> same directory. This can cuase severe confusion since the kernel
> assumes that this will never happen. Depending on which one gets
> found first, and what is cached in the dentry cache, you'll get one
> inode or the other.
>
> E2fsck doesn't normally notice these sorts of inconsistencies, since
> it takes too much time and memory to look for duplicate entries. If
> you optimize directories using "e2fsck -fD", it will find and offer to
> rename directory entires with a duplicated name.
Is not that a little dangerous? I'd expect filesystem to be
okay after doing plain normal check.
What about at least documenting it in BUGS section of man
page?
--
Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...