Re: Unionfs
On Sun, Dec 08, 2002 at 09:04:11AM +0100, Moritz Schulte wrote: > > Also, I find it a bit unfortunate that a simple `ls' triggers this > > already: > > > > wj@hurd:~/unionfs$ settrans -ac foo unionfs .. / > > wj@hurd:~/unionfs$ ls foo/unionfs/ > > ls: foo/unionfs/foo: Too many levels of symbolic links > > Of course; that is exactly the problem we were speaking about on IRC. > If you would be allowed to lookup foo/unionfs/foo, this would lead to > endless recursion - wouldn't be so nice for e.g. the locatedb-find > process. Still, I find it a bit unfortunate that a simple `ls' triggers this already. ;-) How about giving it the appearance of an empty directory instead? Then dired mode and `ls -l' etc. would not fail when looking at the parent directory of the node in question; I don't think it would cause any harm. Cheers, GNU/Wolfgang ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Unionfs
Wolfgang Jaehrling <[EMAIL PROTECTED]> writes: > /usr/bin/ld: netfs.o(.debug_info+0x6399): unresolvable relocation > against symbol `_netfs_translator_callback1' I am not sure what this is; I don't see it here. > I noticed that lnode_ref_remove() and lnode_uninstall() recursively > call each other, where lnode_uninstall() calls lnode_ref_remove() on > node->dir, which should be locked; I could not find anything that > indicates that it will be. Hmm, I will look into that. > Also, I find it a bit unfortunate that a simple `ls' triggers this > already: > > wj@hurd:~/unionfs$ settrans -ac foo unionfs .. / > wj@hurd:~/unionfs$ ls foo/unionfs/ > ls: foo/unionfs/foo: Too many levels of symbolic links Of course; that is exactly the problem we were speaking about on IRC. If you would be allowed to lookup foo/unionfs/foo, this would lead to endless recursion - wouldn't be so nice for e.g. the locatedb-find process. Thanks for your comments. moritz -- [EMAIL PROTECTED] - http://duesseldorf.ccc.de/~moritz/ GPG fingerprint = 3A14 3923 15BE FD57 FC06 B501 0841 2D7B 6F98 4199 ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Filesystem corruption bug in libdiskfs
Hi. In diskfs_rename_dir, filesystem corruption can result if a directory is moved that by a user who cannot write to the parent directory. For example: $ sudo chown -R tla.tla /src/hurd $ mv /src/hurd /home/tla ext2fs.static: /libdiskfs/dir-renamed.c:202: diskfs_rename_dir: Assertion `tmpnp == fnp' failed. The cause of this is that the filesystem is modified (the source directory's .. node is changed, and a reference is added to the target dir to point to the source dir) before any check is made for writability to the parent node. -- Richard Smith ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
pump
Can we please remove pump? It is so horribly broken that there is no point in having it in the tree. If anyone needs to see how the DHCP stuff was done they can always look in the Attic. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: pump
> Can we please remove pump? Kapow. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: 2nd attemt at reviving the filesystem limit discussion.
Marcus Brinkmann <[EMAIL PROTECTED]> writes: > The reason for the limit is because the address space on IA32 architecture > is 32 bit. The memory size must actually be limited on all architectures, because the interfaces are supposed to be machine independent, which requires the word size of the relevant parameters to be constant. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: 2nd attemt at reviving the filesystem limit discussion.
> The memory size must actually be limited on all architectures, because > the interfaces are supposed to be machine independent, which requires > the word size of the relevant parameters to be constant. That's insane. The interfaces on 64-bit machines use 64-bit sizes. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: 2nd attemt at reviving the filesystem limit discussion.
Roland McGrath <[EMAIL PROTECTED]> writes: > > The memory size must actually be limited on all architectures, because > > the interfaces are supposed to be machine independent, which requires > > the word size of the relevant parameters to be constant. > > That's insane. The interfaces on 64-bit machines use 64-bit sizes. This breaks network transparency, and is a bug in the MK8x versions of the kernel, that had to be fixed in the NORMA versions. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Filesystem corruption bug in libdiskfs
, | Abstract <[EMAIL PROTECTED]> writes: | In diskfs_rename_dir, filesystem corruption can result if a directory is | moved that by a user who cannot write to the parent directory. For | example: | $ sudo chown -R tla.tla /src/hurd | $ mv /src/hurd /home/tla | ext2fs.static: /libdiskfs/dir-renamed.c:202: diskfs_rename_dir: | Assertion `tmpnp == fnp' failed. | | The cause of this is that the filesystem is modified (the source | directory's .. node is changed, and a reference is added to the target dir | to point to the source dir) before any check is made for writability to | the parent node. ` This bug is fixed in the CVS version already. -- _.|_ (_||_) Free as in Freedom ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd