Once a file is detected as having a name conflict we do not reexamine it once the duplicate file is deleted. We do that for performance reasons and functionality reasons. The performance reason is that we do not wish to revist the 8.3 name generation every time we delete a file. The functionality reason is that something may now depend on the name of the file being FOOBAR~1.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > mailto: hawleyr@netapp.com mailto:hawleyr@netapp.com US Mail: Network Appliance Inc. > Phone: 408-822-6661 2770 San Tomas Expressway > FAX: 408-822-4457 Santa Clara, CA 95051
-----Original Message----- From: Todd C. Merrill [mailto:tmerrill@mathworks.com] Sent: Friday, June 18, 1999 8:58 AM To: toasters@mathworks.com Cc: Todd C. Merrill; Michael Mirman Subject: files that differ by case only (via CIFS); forced 8.3 notation sticks when one is removed
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 ---