Dr. Michael J. Chudobiak wrote: > > Hi all, > > I tried to make my /home directory a symlink to something on a different > disk (i.e., symlink across filesystems). It appeared to work fine when > browsing directories, but mail delivery stopped! > > I'm using Postfix, with procmail doing the local delivery. > > Is there any reason that procmail (or anything else) would fail if /home > is a symlink? > > - Mike > It depends on: - What shell you're using: When presented with a directory symlink like "/home/A -> /tmp/A", environment variable HOME defined as "/home/A", and the command "cd $HOME", some shells (sh for example) won't update the cwd variable when they get there. Thus the shell (sh in this example) will yield funny results: # cd $HOME # echo $PWD /home/A # pwd /home/A # /bin/pwd /tmp/a # While tcsh and ksh will show: # cd $HOME # echo $PWD /home/A # pwd /tmp/A # /bin/pwd /tmp/A # So... using the shells you normally run, you need to test this and if you get different answers for "where am I?" in the above scenario, you might want to consider switching to a shell that doesn't do this _or_ altering how "cd" behaves by having it do "cd $1; cd `/bin/pwd`" instead of just "cd $1" (and depending on how your normal shell's .rc file is set up, you may also need to apply this trick to the pushd/popd and "set prompt" aliases/sets/commands, too. - What you've set your HOME environment variable to. If $HOME is set to the pointer part of a symlink and not the pointee, you'll run into the problem I described above more often. - The type of symlink reference you've used. "/home/A -> /tmp/A" will normally cause less trouble than "/home/A -> ../../tmp/A". and - The specific formulas you've used in .procmailrc. It's little gotchyas like these that make symlinked HOME directories tougher than necessary to pull off. One trick that normally helps in this situation is to redefine HOME in your shell's .rc (or better yet, .login) file via something like: setenv HOME `/bin/pwd` Hope this helps'idly, -S