Matus fantomas Uhlar wrote: > i mean like > > /a -> /mount/a > /b -> /mount/b Ew... /symlinks to network mounted locations are not recommended. Which is my way of saying they are a very bad thing. One 'ls -l /' and you find yourself hanging waiting for a down network. I am very sensitive to that since in the old days a 'ps' would nlist the kernel in / and ps would have if there was a network problem. Fixed now but there are other issues. > /mount is mountes via autofs. ls -l /mount doesn't show anything after > mount. ls -l /a /b shows only symlinks, but ls -l /a/ /b/ will mount both. > (of course, if you don't have ls aliased with -L, -F etc which would stat > the destination) Agreed. Thanks for the clarification. > What I want to say: there is no possibility to change to /mount/a until I > explicitly try the path or the symlink. changing to /mount will not show I know what you mean. But you said it. This works. cd /mount/a > anything. This is not good for window applications and users which don't > want to 'enter' the filename or directory manually. Ah, so the real problem comes through. For your windows application you might consider 'direct' maps instead of 'host' or 'indirect' maps. However, they can be painful because they need to be driven as things change. A complete list of all available mounts. And an 'ls -l' of the trigger point can cause a mount storm. Doing a test it appears that the default linux kernel limits the number of mounts to 250 at any given time. And autofs did not recover well. I had to stop it and manually unmount the mount points. It did not want to automount unmount them at timeout itself for some reasons. > -> It is not possible. When you stat() a file you will need to get the > -> inode information which is stored on the NFS server not on the client > -> automounter. The automounter must mount the underlying disk in order > -> to get that information. (This is one cause of "mount storms" in the > -> above mentioned not-recommended configurations. Running 'ls -l' on a > -> symlink farm will stat() each and mount all.) > > of course, the information should be fake until the underlying filesystem is > mounted. But it would help in the case i described above Of course if you break the normal system disk paradigm other people will strongly claim it is a bug. So it can't show made up data. Thanks for the clarifications. I think we are on the same page now. Bob
Attachment:
pgpVz8aj3yzl1.pgp
Description: PGP signature