Coda file system is being mounted om /mnt/coda instead of /coda which breaks filesystem functionality. Coda has its standard root at /coda like AFS at /afs and DFS at /... (dot dot dot). This must be respected to enable normal Coda functionality. Otherwise references to files on Coda break. Coda is being used across different distributions, administration domains and on different platforms. /coda file hierarchy contains many realms and files and there are important applications looking for files there at certain paths. As the simplest example I can name mozilla which breaks when a shared home directory has different path names on different hosts. There are lots of similar and different situations where path name globality is vital. Globality is an extremely valuable feature of Coda and Gentoo users should not be deprived of it. Best regards, Rune
Reassigning as I'm transferring maintenance to net-fs. net-fs, the setting he's talking about is in /etc/coda/venus.conf.ex (a configuration file example) and is set to /mnt/coda from the ebuild with sed.
This looks untouched since a year ago. Not running Gentoo myself can not easily check. If it is fixed in reality, the fact should be reflected here as well. Note that the package is very broken unless fixed. Rune
I'm at the moment testing new ebuilds for Coda 6.9.3, which should fix this by setting compatibility symlinks for /coda and so on, to enable apps that expect the monuntpoint to be there to work. Take a look at bug #193012 comment #9 for more info, testing of the new ebuilds would be very appreciated, thanks! Best regards, chtekk.
In the end Coda didn't work out for my particular setup, so I'm reassigning this to maintainer-needed, as I won't be using it. Best regards, chtekk.
Assigning to herd
Marking as depending on bug #193012, as that one has a fix to this situation and other problems. Rune, or anybody familiar with coda: I would like to hear some feedback on the points I raised in last comment(s) of that bug..
(In reply to comment #6) > Rune, or anybody familiar with coda: I would like to hear some feedback on the > points I raised in last comment(s) of that bug.. Unfortunately I do not run any Gentoo machine for the moment and can not comment on Gentoo-specific points nor verify that it works as supposed. The point I am concerned about is that the Coda file system paths must begin with /coda and nothing else and that Gentoo should not offer an installation which would not work as supposed. The globally valid paths are a vital part of "supposed", they are part of Coda. Think if one would ship a web browser where all urls would have to be rewritten like "mnt_http://server/path/..." to work. The point with urls and with Coda paths is that they are global. The root mount point for Coda has nothing to do with how local or NFS mounts are traditionally treated. It is a way to connect to a global file name space. This has to be done consistently on all systems which provide a Posix-like interface, otherwise it would break the functionality and create confusion for new users. Thanks for fixing that the /coda/.... should work now (sorry can not verify) Regards, Rune
Thanks Rune! I made the /coda symlink unconditional (always installed) in the last version (not yet in the tree, I am planning to add it, may be even today). I have just one short question: From looking at the code and manual^{1}, I understand that: /vice and /viceXX dirs are unnecessary if *only client* is installed and /coda and .../venus.cache/ dirs are unnecessary if *only server* is installed. Is this right? If the users later changes his mind and wants to add a server or client capability he will have to re-emerge the package anyway (he can keep the configs, this is out of our hands), so such change will not cause any problems.. [1] BTW, is there any other/more detailed description of coda layout and related things, other than coda-manual.ps that I found on the web site? (besides description of internal structs, which are very nice to have in the open, but are not that usefull to distributor and end users)
Hi George, > Thanks Rune! I made the /coda symlink unconditional (always installed) in the > last version Good! > From looking at the code and manual^{1}, I understand that: > /vice and /viceXX dirs are unnecessary if *only client* is installed and > /coda and .../venus.cache/ dirs are unnecessary if *only server* is installed. > Is this right? Right. > [1] BTW, is there any other/more detailed description of coda layout and > related things I think the layout of files used by the server or the client does not belong to upstream, every distribution can freely choose it. Historically the server puts its configuration and state under /vice and data under /vicepa* which is convenient for seasoned Coda administrators but does not matter otherwise. Personally I prefer putting all of the client files under one dedicated directory, similarly for the server. This is implemented in the cocli and coser distro-independent installers. You may look at the layout under respectively /.cocli-GFjetQfg and /vice after default installation from http://www.aetey.se/index.php?Static&pg=CodaInstHowto Note that it is safe to install/remove these packages, they do not change any other files nor leave traces when removed. Such layout is of course the opposite of the traditional *nix practice of dispersing files. You may also consider to include in the compilation the patches from Aetey (the url above) as there is a configurable clog command and much better Kerberos support and also support for public key anonymous authentication (useful for secure readonly access). Otherwise with vanilla upstream ./configure --enable-client --disable-server and vice versa lets the "make install" command to only install the relevant parts. Regards, Rune
dropped
