Yes, that is intended behavior.
If two names differ only by case, the one that is created second is flagged as invalid for CIFS, and CIFS will only know it by its 8.3 name, even if the first name is removed.
CIFS does case insensitive lookups. If we made the second name visible after the first was removed, CIFS user's would see a different file when accessing the first name.
Joan Pearson
At 08:57 AM 6/18/99 , you wrote:
This may not be a bug, may just be the way NT handles files that differ by case only, but I just wanted to be sure....
Say I have two files, created via NFS, that differ in case only, that are longer than 8 characters:
%touch foobar123 %touch fooBar123 %/bin/ls -alF foo* -rw-r--r-- 1 toddc users 0 Jun 18 11:46 fooBar123 -rw-r--r-- 1 toddc users 0 Jun 18 11:45 foobar123
On a Windows NT box (4.0 SP3), they appear as:
H:>\ dir foo* 06/18/99 11:45a 0 foobar123 06/18/99 11:46a 0 FOOBAR~1
If I remove foobar123 from an NFS mount:
%rm foobar123
the Windows box then shows:
H:>\ dir foo* 06/18/99 11:46a 0 FOOBAR~1
Why doesn't it show the file as "fooBar123" now? How come it is stuck with the forced 8.3 notation?
It still appears with the original name via the NFS mount:
%/bin/ls -alF foo* -rw-r--r-- 1 toddc users 0 Jun 18 11:46 fooBar123
The only way I can force it back is to rename it to something else and then rename it back to the original name:
% mv fooBar123 fb; mv fb fooBar123 % /bin/ls -alF foo* -rw-r--r-- 1 toddc users 0 Jun 18 11:46 fooBar123
H:>\ dir foo* 06/18/99 11:46a 0 fooBar123
I don't fully understand the behavoiur of Windows naming, so any light shed upon this would be great. If this is expected behaviour, well, I guess we'll just have to deal with these errors as they crop up in our automated test environment.
(NetApp Release 5.2.1P2: Tue Mar 16 10:41:03 PST 1999)
Until next time...
Todd C. Merrill The Mathworks, Inc. 508-647-7792 24 Prime Park Way, Natick, MA 01760-1500 508-647-7012 FAX tmerrill@mathworks.com http://www.mathworks.com