[OpenAFS] Crash testing OpenAFS
Sun, 14 Aug 2005 07:53:11 -0700
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
From: email@example.com [mailto:firstname.lastname@example.org]
On Behalf Of Jeffrey Altman
Sent: Sunday, August 14, 2005 5:28 AM
To: ted creedon
Subject: Re: [OpenAFS] Crash testing OpenAFS
ted creedon wrote:
>>>This is possibly the case. A month or 2 ago I dragged the same
> 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.