From: Craig_Everhart@transarc.com
Date: 03/25/97-01:53:13 PM Z
Message-Id: <QnC2odaSMUQe0EGaI0@transarc.com> Date: Tue, 25 Mar 1997 14:53:13 -0500 (EST) From: Craig_Everhart@transarc.com Subject: Re: Attributes Excerpts from transarc.external.nfs4-wg: 25-Mar-97 Re: Attributes Carl Beame@homenet.ie (961) > Imagine a PC client talking to a sever which does not implement > filesize. A simple DIR /S would cause the client to read EVERY file on > the mounted drive to get the file size, since a directory always > returns the information and DOS/WINDOWS programs often use this > information immediately. > I understand under VMS cooked files need to be read by the server > before they can return the file size. Would you rather have the server > read the file once and cache the file size or 1000 PC clients read the > file 1000 times? I was thinking about a similar version of this problem. If ``file size'' is used by clients for two purposes: (a) to tell exactly how many bytes may be read from this file (b) as an aid in simplistic cache management then it's problematic to define a single, optional, file size attribute, since servers that have trouble implementing an exact byte count will be unwilling to do that work as part of every bundled attribute set. Might it make sense to define two optional attributes: (1) exact file size in bytes (2) size-change opaque cookie and expect to get one of them back from any server? One could maybe even say that (2) should be some numeric approximation to (1) but it doesn't have to be exact. Or define a ``(3) approximate size'' attribute. One could advance a similar argument for mtime's use both as a data modification time and as a guard on data changing. Why not a separate (small!) attribute as a data-change opaque cookie? A ``data version number'' if you will. Craig
This archive was generated by hypermail 2.1.2 : 03/04/05-01:45:42 AM Z CST