I have an application that works 100% in windows 2000 on an ntfs volume.... I install it on windows nt (ntfs volume) and a small part of the application does not work. The name of the directory is 9 characters long (for both workstations). If I change this directory name to 8 characters, it all works. With a 9 character directory name, 99% of the application works - just that one part doesn't. What is the difference between the ntfs on NT versus 2000?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
ntfs - windows 2000 & windows NT - what's the difference
- Thread starter kida
- Start date
NT will use NTFS4 and 2k NTFS5 as Aslam says. NT4sp4/5/6 updates the ntfs.sys file to allow NT to read NTFS5, but it doesn't give it the full functionality. The only real mainstream differences are encryption, mount point and disk quota management.
As far as your long filename goes, it doesn't really make sense. When you save a file with a long file name to an NTFS4 drive, NT creates a second file directory entry with a short file name conforming to the 8.3 convention. When you access the file, NT accesses the conventional file name and the delay is so tiny you wouldn't notice it. Thus, it should work and shouldn't take any longer (ie won't timeout or anything).
HOWEVER it may be that, if your application is a 16-bit one, 2k is managing the program better than NT (not hard!) and it's navigating this issue. Certainly I've seen countless apps that refused to work on NT thanks to Admins who'd disabled 8.3 file naming to try and increase performance and/or make their directory structures all long-name. Looking at your app's behaviour though, I can't see this being the case. If you can just change the directory name and it works, it's not the sort of app that likes everything in it's place with a nice 8.3 name or it won't work.
To be honest, the only suggestion I have is to do what you've done. It's a workaround rather than a solution, but it gets the job done. I'll keep stewing on this though, so if anyone does have a light-bulb flicker on, post something and put us out of our misery!
As far as your long filename goes, it doesn't really make sense. When you save a file with a long file name to an NTFS4 drive, NT creates a second file directory entry with a short file name conforming to the 8.3 convention. When you access the file, NT accesses the conventional file name and the delay is so tiny you wouldn't notice it. Thus, it should work and shouldn't take any longer (ie won't timeout or anything).
HOWEVER it may be that, if your application is a 16-bit one, 2k is managing the program better than NT (not hard!) and it's navigating this issue. Certainly I've seen countless apps that refused to work on NT thanks to Admins who'd disabled 8.3 file naming to try and increase performance and/or make their directory structures all long-name. Looking at your app's behaviour though, I can't see this being the case. If you can just change the directory name and it works, it's not the sort of app that likes everything in it's place with a nice 8.3 name or it won't work.
To be honest, the only suggestion I have is to do what you've done. It's a workaround rather than a solution, but it gets the job done. I'll keep stewing on this though, so if anyone does have a light-bulb flicker on, post something and put us out of our misery!
- Status
