Re: FW: Symbolic link with absolute target path in UDF - not working properly?

[Jan Kara <jack@suse.cz>]

On Tue 13-12-11 19:30:32, Joerg Schilling wrote:
> Jan Kara <jack@suse.cz> wrote:
> 
> > > AFAIK, Linux does getcwd() in kernel as Solaris does, so it should be possible 
> > > to get the path for a mount point, in case that path was not kept during the 
> > > mount(2) operation.
> >   Jorg, maybe I'm missing something but look:
> > quack:/tmp/foo # l
> > total 700
> > drwxr-xr-x  2 root root   4096 2011-12-13 16:54 ./
> > drwxrwxrwt 74 root root 712704 2011-12-13 16:54 ../
> > quack:/tmp/foo # mkdir -p bar/baz
> > quack:/tmp/foo # mkdir bar2
> > quack:/tmp/foo # mount -t ext3 -o loop ~jack/fs-images/ext3-image bar/baz/
> > quack:/tmp/foo # mkdir bar/baz/dir
> > quack:/tmp/foo # touch bar/baz/dir/some_file
> > quack:/tmp/foo # mount --bind bar/baz/dir/ bar2
> 
> This looks loks a loopback mount.
  The first mount is the loopback one, right. But that's not really
interesting. What is interesting is the second mount --bind which allows
you to mount arbitrary *directory* over some other directory in the system.
So you have two (consistent) copies of one directory and it's subtree in the
system.

> > quack:/tmp/foo # ls bar2
> > some_file
> > quack:/tmp/foo # ls bar/baz/
> > aquota.group  aquota.user  dir
> > quack:/tmp/foo # mount -t ext2 -o loop ~jack/fs-images/ext2-image bar/
> > quack:/tmp/foo # l bar
> > total 18
> > drwxr-xr-x 4 10005 users  1024 2011-02-24 12:18 ./
> > drwxr-xr-x 4 root  root   4096 2011-12-13 16:55 ../
> > drwx------ 2 root  root  12288 2010-03-10 12:21 lost+found/
> > drwxrwxrwx 6 root  root   1024 2011-02-24 12:18 t/
> > quack:/tmp/foo # 
> >
> >   So to summarize we have directory structure like:
> > 		/tmp
> > 		  |
> > 		 foo
> > 		/   \
> > 	      bar   bar2
> > 	       |     |
> > here is ext2_image  here is subtree of 'dir' from ext3_image
> 
> If this is implemented the way it is implemented in Solaris, there is a
> nearly empty vfs layer, specific to the loopback mount that indirectly
> calls the vfs functions for the base FS. So on Solaris this is 
> possible and it would work as expected. 
  Again, note that loopback mounts are not the hard part here. I could have
mounted standard block devices and nothing interesting would have changed
in my example. What is interesting is that I can create a directory tree
where root of some filesystem is not accessible (there is not a valid path
that would resolve to it) but it's subdirectory is accessible.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR