Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On Wed, Jan 30, 2013 at 11:39 AM, Daniel Hagerty <hag at linnaean.org> wrote: > Bill Bogstad <bogstad at pobox.com> writes: > >> Which as of the 1995 version 3 RFC, clearly defines LINK and SYMLINK >> protocol commands. Unfortunately, it also documents that some >> servers might not support LINK or even SYMLINK and introduces a FSINFO >> command that a client can use to determine ahead of time if a server >> supports these or other features. So the real answer is "it depends" >> on your local implementation. See > > Yes, well, there's always room for that :) > > I still have un-fond memories of a certain platform whose > implementation of nfsv3 mknod() was panic(). Was that an actual call of panic() (or equivalent) or just a crash due to an unrecognized command? What I probably should have said, is that at least as of V3 NFS; it was a documented exception that a system could claim to "do NFS" and not support LINK or SYMLINK. OTOH, if both the client and server are Unix-like systems and the filesystem on the server natively supports LINK; then chances are it will work. The further you get away from that configuration though the more likely you are to have problems and just finding "NFS V3" on the bullet list of features isn't going to tell you anything. Bill Bogstad
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |