The 1.7.1 release for Windows has been posted to the openafs.org web
site.  A formal release announcement will be issued morning EDT.

Jeffrey Altman


On 9/6/2011 9:53 PM, Jeffrey Altman wrote:
> The release will be issued from openafs.org.
> 
> The release will be an official release from the openafs-devel-1_7_x branch.
> 
> I'm not going to qualify it as beta any more than Apple qualifies a new
> major release as beta.  The code has been heavily tested and implements
> just about everything an application can ask of a Windows file system. 
> It is better integrated with Windows than all of the previous SMB based
> clients.  Will it work perfectly for all applications ever developed? 
> Probably not.  There are bound to be some use cases that the code has
> simply never been exposed to.  Will the code work better than the SMB
> based client for most users?  Absolutely, especially if they are on
> Windows 7.   Are there still things that can be done to improve it?
> Definitely.
> 
> I will discuss the future as part of the release announcement.
> 
> Jeffrey Altman
> 
> 
> 
> On 9/6/2011 1:14 PM, Ben Howell wrote:
>> Will that "release" on/about Sep. 15 be a alpha/beta/dev release, or
>> an actual public release?
>>
>>  - Ben
>>
>> On 9/3/11 1:44 PM, Jeffrey Altman wrote:
>>> On 9/3/2011 11:01 AM, Lars Schimmer wrote:
>>>> Hi!
>>>>
>>>> Due to the outstanding Windows 7 bug annoying us very deeply, we search
>>>> for a solution to this problem.
>>> The solution to the Windows 7 bug is the OpenAFS for Windows client with
>>> native installable file system driver which will be released as the
>>> 1.7.x development series.
>>>
>>> Now that 1.6.0 has finally been released work will begin on creating the
>>> openafs-devel-1_7_x branch from which the IFS windows client will be
>>> issued.  The first official release from OpenAFS.org will be 1.7.1.  I
>>> am hoping that we will be able to release on or around the 15th of Sept.
>>>
>>> The IFS client will bring some significant changes from the SMB client.
>>>
>>> No Loopback Adapter
>>> -------------------
>>>
>>> Now that a native IFS driver (afsredir.sys / afsredirlib.sys) is used,
>>> there is no need to install the Microsoft Loopback Adapter.  Sites that
>>> have experienced problems due to the 10.254.254.253 address registration
>>> on multiple machines will be able to remove or disable the adapter once
>>> and for all.
>>>
>>> No Delays After a Resume
>>> ------------------------
>>>
>>> Windows Vista and 7 shutdown the network stack when the machine is
>>> suspended.  This causes problems when the machine resumes because the
>>> network path to \\AFS is not immediately accessible.  This is no longer
>>> an issue with the IFS driver.
>>>
>>> No "AFS" server name collisions
>>> -------------------------------
>>>
>>> It is now possible to add a machine named "AFS" to domain or subnet
>>> without breaking the OpenAFS for Windows client.
>>>
>>> Performance Improvements
>>> ------------------------
>>>
>>> The transaction rate and throughput performance of the SMB client was
>>> limited by the "SMB client<->  loopback<->  SMB server" performance:
>>> 54MB/sec maximum on 32-bit systems and 63MB/sec on 64-bit systems.  The
>>> IFS client is capable of throughput rates to/from cache up to 800MB/sec
>>> depending on the system I/O bus and backing store capabilities.
>>>
>>> Symlinks to UNC Paths permit a cohesive name space
>>> --------------------------------------------------
>>>
>>> It has always been possible to create reparse points in MS DFS that
>>> refer to \\AFS paths.  It is now possible to create symlinks in AFS
>>> that refer to arbitrary UNC paths.  This permits the construction of
>>> a cohesive name space that spans across both AFS and DFS storage.
>>>
>>> Reparse Points
>>> --------------
>>>
>>> AFS Mount Points and Symlinks are exported by the file system
>>> as Windows reparse points with a Microsoft assigned tag value.
>>> Tools that are OpenAFS reparse point aware can create, query
>>> and remove AFS symlinks and mount points without requiring knowledge
>>> of AFS pioctls.  The explorer shell will be able to delete a mount
>>> point or symlink as part of a recursive directory tree removal without
>>> crossing into the reparse point target.
>>>
>>> AFS Volumes are Windows File Systems
>>> ------------------------------------
>>>
>>> Each AFS volume is represented in the Windows kernel as a distinct
>>> file system.  This will permit AFS volume quotas to viewed as
>>> Windows file system quotas.
>>>
>>>
>>> Authentication Groups
>>> ---------------------
>>>
>>> AFS Tokens are associated with Windows user names in the SMB client.
>>> With the IFS client, tokens are associated with Authentication Groups.
>>> By default, an authentication group is allocated for each User SID
>>> and Logon Session Id combination.  In addition, it is possible for
>>> processes to create additional Authentication Groups.  Each thread in
>>> a process can select an Authentication Group within the process as the
>>> active Authentication Group.  This will permit AFS aware IIS modules
>>> to associate AFS credentials with a particular incoming request.  An
>>> IIS implementation of File Drawers will be the preferred implementation
>>> once it is developed.
>>>
>>> One of the significant benefits of Authentication Groups within the
>>> Windows environment is that Windows services (svchost.exe, csrss.exe,
>>> etc.) which impersonate user processes will seamlessly gain access
>>> to the user's AFS credentials for the lifetime of the impersonation.
>>>
>>>
>>> Explorer Shell Integration
>>> --------------------------
>>>
>>> The AFS Explorer Shell integration will gain support for symlink
>>> and mount point overlay icons, tool tips, and Property dialog pages
>>> that replace many of the existing AFS Context Menu dialogs.
>>>
>>>
>>> Jeffrey Altman
>>>
> 

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to