Hello,
Look what I found in the mailist list archive :
From madhatta Tue Nov 18 18:52 EST 1997 Received: from odin.netapp.com (odin.netapp.com [198.95.224.183]) by turing.mathworks.com (8.8.5/8.7.3) with ESMTP id SAA03647 for toasters@mathworks.com; Tue, 18 Nov 1997 18:51:35 -0500 (EST) Received: from herra.netapp.com (172.20.6hide.netapp.com [198.95.224.200]) by odin.netapp.com (8.8.7/8.8.7/GNAC-GW-2.1) with ESMTP id PAA11514; Tue, 18 Nov 1997 15:44:32 -0800 (PST) Received: from netapp.com (keith-pc.netapp.com [172.20.6.61]) by herra.netapp.com (8.8.7/8.8.7/GNAC-GW-2.1) with ESMTP id PAA26897; Tue, 18 Nov 1997 15:47:38 -0800 (PST) Message-ID: 3472290E.C00B8959@netapp.com Date: Tue, 18 Nov 1997 15:47:27 -0800 From: Keith Brown keith@netapp.com Reply-To: keith@netapp.com Organization: Network Appliance, Inc. X-Mailer: Mozilla 4.02 [en] (Win95; I) MIME-Version: 1.0 To: quinlan@transmeta.com CC: toasters@mathworks.com Subject: Re: links using CIFS References: 199711182300.PAA22605@sodium.transmeta.com Content-Type: multipart/mixed; boundary="------------FBDEBC85A108A84A65F02E8D" Content-Length: 2731 X-Keywords: Status: RO X-Status:
This is a multi-part message in MIME format. --------------FBDEBC85A108A84A65F02E8D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit
Daniel Quinlan wrote:
Could someone explain exactly what works and what doesn't when using symbolic links from a CIFS client (Windows95 or WindowsNT, primarily) from a Netapp with Unix symbolic links?
Certainly.
In Data ONTAP releases prior to 4.3, Windows systems saw symbolic links that had been created in the WAFL file system (from the UNIX side) as exactly what they *really* are. That is to say, plain files which contain the full or relative pathname to the place that they are a symbolic link to. Technically, the UNIX symlink attribute has no meaning in the Windows client world, and so they don't treat symlink files as "special" in the same way that UNIX systems do.
However, in our brand spanking new 4.3 release, this has changed. If you install and run this release on your filer(s), you will find that Windows systems will now automagically follow UNIX symlinks, with a single, necessary limitation. The symlink must point to a place that the client *can* actually make the jump to. The client can only be redirected to another location under the same share in which it encountered the symlink in the first place. Just in case you have designed your symlinks in such a way that this is not entirely feasible for you to easily arrange, the new mechanism also features a symlink pathname translation mechanism that works very simililarly to the existing "httpd.translations" mechanism with which customers may already be familiar. You can use this mechanism to yank meandering symlinks back into your share, but of course you probably have to put a copy of the data that they were originally going to take you to in the share also.
Ooh.. I should probably mention that the new symlink following feature does contain machinery to stop a Windows client from looping in a file system when it is following the symlinks. That base is covered! :-)
Keith
This mentions Release 4.3. However, I'm on 5.1D4 and does this work ? In a word : NO.
Yours beleaguredly,
Raymond the Depressed
"Your future depends on your dreams. So go to sleep "- Lao Tse