From patchwork Wed Jan 4 07:48:19 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sachin Prabhu X-Patchwork-Id: 9496215 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id B91C260413 for ; Wed, 4 Jan 2017 07:48:35 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A09C226E8A for ; Wed, 4 Jan 2017 07:48:35 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 82C21272F9; Wed, 4 Jan 2017 07:48:35 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0278D26E8A for ; Wed, 4 Jan 2017 07:48:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757240AbdADHsd (ORCPT ); Wed, 4 Jan 2017 02:48:33 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60066 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757236AbdADHsd (ORCPT ); Wed, 4 Jan 2017 02:48:33 -0500 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EEC3781243 for ; Wed, 4 Jan 2017 07:48:23 +0000 (UTC) Received: from sprabhu-lp.pnq.redhat.com ([10.76.1.79]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v047mK2A004668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 Jan 2017 02:48:22 -0500 From: Sachin Prabhu To: linux-cifs Cc: Jeff Layton Subject: [PATCH] Document mfsymlinks in the mount.cifs man page Date: Wed, 4 Jan 2017 13:18:19 +0530 Message-Id: <1483516099-24421-1-git-send-email-sprabhu@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Wed, 04 Jan 2017 07:48:24 +0000 (UTC) Sender: linux-cifs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-cifs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Information from the cifs README in the kernel sources is used. Signed-off-by: Sachin Prabhu --- mount.cifs.8 | 5 +++++ 1 file changed, 5 insertions(+) &. diff --git a/mount.cifs.8 b/mount.cifs.8 index af6b097..01579f6 100644 --- a/mount.cifs.8 +++ b/mount.cifs.8 @@ -450,6 +450,11 @@ sfu When the CIFS Unix Extensions are not negotiated, attempt to create device files and fifos in a format compatible with Services for Unix (SFU)\&. In addition retrieve bits 10\-12 of the mode via the SETFILEBITS extended attribute (as SFU does)\&. In the future the bottom 9 bits of the mode mode also will be emulated using queries of the security descriptor (ACL)\&. [NB: requires version 1\&.39 or later of the CIFS VFS\&. To recognize symlinks and be able to create symlinks in an SFU interoperable form requires version 1\&.40 or later of the CIFS VFS kernel module\&. .RE .PP +mfsymlinks +.RS 4 +Enable support for Minshall+French symlinks(see http://wiki.samba.org/index.php/UNIX_Extensions#Minshall.2BFrench_symlinks). This option is ignored when specified together with the 'sfu' option. Minshall+French symlinks are used even if the server supports the CIFS Unix Extensions. +.RE +.PP serverino .RS 4 Use inode numbers (unique persistent file identifiers) returned by the server instead of automatically generating temporary inode numbers on the client\&. Although server inode numbers make it easier to spot hardlinked files (as they will have the same inode numbers) and inode numbers may be persistent (which is userful for some sofware), the server does not guarantee that the inode numbers are unique if multiple server side mounts are exported under a single share (since inode numbers on the servers might not be unique if multiple filesystems are mounted under the same shared higher level directory)\&. Note that not all servers support returning server inode numbers, although those that support the CIFS Unix Extensions, and Windows 2000 and later servers typically do support this (although not necessarily on every local server filesystem)\&. Parameter has no effect if the server lacks support for returning inode numbers or equivalent\&. This behavior is enabled by default\!