[OpenAFS] Crash testing OpenAFS

[ted creedon]

Well the test case does not have that problem. At least to where it carps.

Taking a worst case scenario can one drag and drop a entire windows C: drive
to AFS and back again and expect a faithful reproduction? Since the source
files are not in conflict in the first place one would expect a round trip
to work.

tedc
-----Original Message-----
From: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org]
On Behalf Of Jeffrey Altman
Sent: Sunday, August 14, 2005 5:28 AM
To: ted creedon
Cc: openafs-info@openafs.org
Subject: Re: [OpenAFS] Crash testing OpenAFS

ted creedon wrote:
>>>This is possibly the case. A month or 2 ago I dragged the same 
>>>directory
> 
> from the 1.2.11 to a windows firewire drive using the Windows client 
> and observed duplicate filename messages from the windows boxes.

Local Windows file systems are case-preserving but not case-sensitive.
   If you copy a directory tree from AFS (which is case-sensitive) to a
local file system and the tree contains files that are different only in the
case of the characters:

 1/31/2005  14:38         <DIR>    foo
 9/28/2004   8:22         <DIR>    FOO
 8/14/2005   8:21               0  FoO
 8/14/2005   8:21               0  Foo

then you are going to run into collisions.   The Windows OpenAFS client
will do its best to distinguish between these four entries by using a
case-sensitive first pattern matching followed by a case-insensitive
pattern matching if that fails.   With the above four entries the client
will not allow any access to "fOO" or "foO" because the case-insensitive
match is ambiguous.  This is usually not an issue when using Windows GUI
dialogs because the file name matchs are always case-sensitive.	

> Jaltman mentioned that long filenames are not necessarily unique under 
> AFS, however they are unique in my 1.2.11 AFS filesystem, I don't know 
> about the 1.3.87 filesystem. I'll investigate.

That is not what I said.   See above.

Jeffrey Altman