git.notmuchmail.org Git - notmuch/blob - test/corpora/lkml/cur/1382298587.003486:2,

   1 From: Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org>
   2 Subject: Re: [RFC][PATCH 05/10] cifs: define superblock-level cache index
   3  objects and register them
   4 Date: Mon, 28 Jun 2010 18:23:13 +0530
   5 Lines: 48
   6 Message-ID: <4C289B39.4060901@suse.de>
   7 References: <22746.1277470713@redhat.com> <4C24A4A0.90408@suse.de> <1277220206-3559-1-git-send-email-sjayaraman@suse.de> <yes> <9720.1277312290@redhat.com> <23204.1277472412@redhat.com>
   8 Mime-Version: 1.0
   9 Content-Type: text/plain; charset=UTF-8
  10 Content-Transfer-Encoding: 7bit
  11 Cc: Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
  12         linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
  13 To: David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  14 X-From: linux-cifs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Mon Jun 28 14:53:24 2010
  15 Return-path: <linux-cifs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
  16 Envelope-to: glkc-linux-cifs-1dZseelyfdZg9hUCZPvPmw@public.gmane.org
  17 Received: from vger.kernel.org ([209.132.180.67])
  18         by lo.gmane.org with esmtp (Exim 4.69)
  19         (envelope-from <linux-cifs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>)
  20         id 1OTDq0-00054Q-At
  21         for glkc-linux-cifs-1dZseelyfdZg9hUCZPvPmw@public.gmane.org; Mon, 28 Jun 2010 14:53:24 +0200
  22 Received: (majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org) by vger.kernel.org via listexpand
  23         id S1754503Ab0F1MxX (ORCPT <rfc822;glkc-linux-cifs@m.gmane.org>);
  24         Mon, 28 Jun 2010 08:53:23 -0400
  25 Received: from cantor2.suse.de ([195.135.220.15]:48374 "EHLO mx2.suse.de"
  26         rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
  27         id S1754456Ab0F1MxW (ORCPT <rfc822;linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>);
  28         Mon, 28 Jun 2010 08:53:22 -0400
  29 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.221.2])
  30         by mx2.suse.de (Postfix) with ESMTP id 7BDC18672B;
  31         Mon, 28 Jun 2010 14:53:21 +0200 (CEST)
  32 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091130 SUSE/3.0.0-1.1.1 Thunderbird/3.0
  33 In-Reply-To: <23204.1277472412-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  34 Sender: linux-cifs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
  35 Precedence: bulk
  36 List-ID: <linux-cifs.vger.kernel.org>
  37 X-Mailing-List: linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
  38 Archived-At: <http://permalink.gmane.org/gmane.linux.kernel/1003530>
  39
  40 On 06/25/2010 06:56 PM, David Howells wrote:
  41 > David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
  42 >
  43 >>>> validate the root directory of the share in some way?
  44 >>>
  45 >>> I don't know if there is a way to do this.
  46 >>
  47 >> Is there an inode number or something?  Even the creation time might do.
  48 >
  49 > Looking in cifspdu.h, there are a number of things that it might be possible
  50 > to use.
  51 >
  52 >  (1) FILE_ALL_INFO: CreationTime, IndexNumber, IndexNumber1, FileName
  53 >      (assuming this isn't flattened to '\' or something for the root of a
  54 >      share.
  55 >
  56 >  (2) FILE_UNIX_BASIC_INFO: DevMajor, DevMinor, UniqueId.
  57 >
  58 >  (3) FILE_INFO_STANDARD: CreationDate, CreationTime.
  59 >
  60 >  (4) FILE_INFO_BASIC: CreationTime.
  61 >
  62 >  (5) FILE_DIRECTORY_INFO: FileIndex, CreationTime, FileName.
  63 >
  64 >  (6) SEARCH_ID_FULL_DIR_INFO: FileIndex, CreationTime, UniqueId, FileName.
  65 >
  66 >  (7) FILE_BOTH_DIRECTORY_INFO: FileIndex, CreationTime, ShortName, FileName.
  67 >
  68 >  (8) OPEN_RSP_EXT: Fid, CreationTime, VolumeGUID, FileId.
  69 >
  70 > You may have to choose different sets of things, depending on what the server
  71 > has on offer.  Also, don't forget, if you can't work out whether a share is
  72
  73 Did you mean we need to validate differently for different servers?
  74
  75 I just did some testing and it looks like we could rely on CreationTime,
  76 IndexNumber for validating with Windows servers (FileName is relative to
  77 the mapped drive) and UniqueId for validating with Samba servers. I did
  78 not test all possibilities (there could be more).
  79
  80 > coherent or not from the above, you can always use LastWriteTime, ChangeTime
  81 > and EndOfFile and just discard the whole subtree if they differ.
  82 >
  83
  84 Thanks,
  85
  86 --
  87 Suresh Jayaraman
  88
  89