-   Solaris / OpenSolaris (
-   -   Solaris 10 - ZSH displays a . when pwd on nfs mount (

waslit 03-18-2013 03:40 PM

Solaris 10 - ZSH displays a . when pwd on nfs mount
To give you a base understanding firsly the client system is running :
SunOS sacqtzl16 5.10 Generic_137112-02 i86pc i386
the host is running :
CentOS release 5.4 (Final)

The cent host is providing a few NFS shares to the solaris box. The share are mounted in a fomat of

host:/zldata01 - /v/host/zldata01 nfs 0 yes vers=3,proto=tcp
host:/zldata02 - /v/host/zldata02 nfs 0 yes vers=3,proto=tcp
host:/zldata03 - /v/host/zldata03 nfs 0 yes vers=3,proto=tcp
host:/zldata04 - /v/host/zldata04 nfs - yes vers=3,proto=t

now those folders are then symlinks to something say /u/data1 -----> /v/host/zldata01
/u/data2 -----> /v/host/zldata02
/u/data3 -----> /v/host/zldata03
/u/data4 -----> /v/host/zldata04

The issue that I'm seeing which is very weird. Is when I go into folder /u/data4/folder/ and run #pwd it returns with #. instead of the full path. This weirdness is only present when using the zsh shell, and appears in both the symlink and the absolute path. And whats even worse is its only on data04. All the others work just as expected. Some things I have noticed is if I run a truss -o test.txt pwd it actually returns the correct path and not a dot. My collegue ran a truss and managed to get an error or 79 which I found out is a overrun of the buffer declaring a variable. Usually when there is a large file involved. Except this is a directory not a file and then name scheme is pretty simple. All the mounts are the same. The underlying file system is xfs. There are no weird errors in messages and we havent rebooted or anything. I have been unable to reproduce this in a lab enviroment either.

pan64 03-19-2013 08:01 AM

you can probably try /bin/pwd
check if there is a function, an alias or something unusual what will make the trick.

waslit 03-19-2013 08:10 AM


Originally Posted by pan64 (Post 4914458)
you can probably try /bin/pwd
check if there is a function, an alias or something unusual what will make the trick.

Very weird but yes that did actually work =) it produced an output. However there is no alias set for pwd??.... hmm very strange and even still why only on 1 folder.

pan64 03-19-2013 08:20 AM

by default pwd is a shell builtin, but also a binary executable exists (that is /bin/pwd). you can check it with the command type pwd. The builtin has some options and also can be ruled by environment variables.

pwd [ -rLP ]
Print the absolute pathname of the current working directory. If
the -r or the -P flag is specified, or the CHASE_LINKS option is
set and the -L flag is not given, the printed path will not
contain symbolic links.

waslit 03-19-2013 08:39 AM

So its the pwd shell version from zsh thats the issue. I'll have to investigate more to find out why. so when I run a truss on the command which is it running? The shell or the binary? I assume the binary since running truss pwd did produce an output as expected. That also isolates it even further to zsh since auto complete does not appear to work. on the folders inside.

waslit 03-19-2013 08:53 AM

Okay very interestingly I have found a coloration with what you mentioned and the buffer over flow my colleague found. Which it all makes sense now. ZSH is a 32bit version and the xfs file system installed is inode64. So it now makes sense that ZSH built in shell command is erroring out when trying to do a listing of the current directory. the next question tho is what to do lol. don't wanna redo everything. So I'll have to figure out something.

pan64 03-19-2013 08:57 AM

you need to check the beginning of the output (of truss). you need to find /bin/pwd.
probably you can try truss -o <file> zsh -c pwd to use the builtin

pan64 03-19-2013 08:59 AM

probably you can try an alias or function to remap to /bin/pwd

All times are GMT -5. The time now is 07:14 PM.