NTFS - Is it reliable?

[Mark Jacobs]

I am having second thoughts as to the efficacy of Windows 2003 server as a mission or business-critical
solution. I assume that it uses NTFS by default, and I am also assuming that this is the cause of my current
woes.

We have an old DOS market research system written in Zortech C (version 2.1 from 1989). It has worked
flawlessly since 1990 when it was released for our various clients' use. They have hammered every aspect of it
over the years, and it has never gone wrong. It was always run under Novell Netware, but recently, we migrated
our office to Windows 2003 Server (SBE). Since then, we have had files intermittently truncated when opened
using fopen with the "a" mode (open for appending and create if it doesn't exist), files in use when they
definitely are not in use, and, just today, the worst of all - a 600KByte file full of respondent details had
its contents replaced by zero (null) bytes, whilst retaining its original size after a simple
fopen(sample,"ab"). What must we do to make our SBE server reliable?

We have tried getting rid of optimistic locking and other caching techniques using the following .reg files :-
------------------------------------------------------------
Client Registry patch (copy and paste into a .REG file if you like) :-

------------------------------------------------------------

Windows Registry Editor Version 5.00



[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VXD\VREDIR]

"DiscardCacheOnOpen"=hex:01

------------------------------------------------------------

2003 Server patch (copy and paste into a .REG file if you like) :-

------------------------------------------------------------

Windows Registry Editor Version 5.00



[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters]

"EnableOpLockForceClose"=dword:00000001

"EnableOplocks"=dword:00000000

"CachedOpenLimit"=dword:00000000

"autodisconnect"=dword:ffffffff

 

[Bob Harris]

Windows 2003 is of the NT,2000,XP familiy, not of the DOS, 3.1, 95,98,ME
family.

In short, 2003 does NOT do DOS. Yes, it has a command prompt that looks
like DOS, but it ain't really DOS.

In particular, 2003 works hard to prevent any program from directly
accessing hardware, which is exactly what old DOS software used to do.

The problem is far less likely ot be NTFS (vs FAT32) as it is that you need
to re-write/re-compile the old program, and remove any direct access to
hardware.

Good luck, you are going to need it.

I am having second thoughts as to the efficacy of Windows 2003 server as a mission or business-critical
solution. I assume that it uses NTFS by default, and I am also assuming

that this is the cause of my current

woes.

We have an old DOS market research system written in Zortech C (version 2.1 from 1989). It has worked
flawlessly since 1990 when it was released for our various clients' use.

They have hammered every aspect of it

over the years, and it has never gone wrong. It was always run under

Novell Netware, but recently, we migrated

our office to Windows 2003 Server (SBE). Since then, we have had files

intermittently truncated when opened

using fopen with the "a" mode (open for appending and create if it doesn't exist), files in use when they
definitely are not in use, and, just today, the worst of all - a 600KByte

file full of respondent details had

its contents replaced by zero (null) bytes, whilst retaining its original size after a simple
fopen(sample,"ab"). What must we do to make our SBE server reliable?

We have tried getting rid of optimistic locking and other caching

techniques using the following .reg files :-

------------------------------------------------------------
Client Registry patch (copy and paste into a .REG file if you like) :-

------------------------------------------------------------

Windows Registry Editor Version 5.00



[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VXD\VREDIR]

"DiscardCacheOnOpen"=hex:01

------------------------------------------------------------

2003 Server patch (copy and paste into a .REG file if you like) :-

------------------------------------------------------------

Windows Registry Editor Version 5.00



[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameter
s]

"EnableOpLockForceClose"=dword:00000001

"EnableOplocks"=dword:00000000

"CachedOpenLimit"=dword:00000000

"autodisconnect"=dword:ffffffff

------------------------------------------------------------

and we are still having the same problems. Does anyone know what is going on? Why is NTFS so much less
reliable than Novell Netware's file system?
--
Mark Jacobs
DK Computing
http://www.dkcomputing.co.uk
(e-mail address removed)

 

[Mark Jacobs]

But the point here is that Novell Netware can do file server work reliably, but 2003 can't. The same .EXE
causes random failures on 2003, but smooth, unruffled operation under Novell. *THAT* is my point : that 2003
cannot hope to contend with Novell on server reliability : that 2003 cannot be deployed for mission or
business-critical applications : that is why businesses are migrating towards Linux/Novell combos to house
their money-making software, especially if that software must be up and running 24/7/365.

 

[Andrew Camfield]

But the point here is that Novell Netware can do file server work reliably, but 2003 can't. The same .EXE
causes random failures on 2003, but smooth, unruffled operation under Novell. *THAT* is my point : that 2003
cannot hope to contend with Novell on server reliability : that 2003 cannot be deployed for mission or
business-critical applications : that is why businesses are migrating towards Linux/Novell combos to house
their money-making software, especially if that software must be up and running 24/7/365.

No, what he's telling you is that in older versions of software, when
you do your file open the compiler translates that into an Interrupt
21h Function 716Ch, which is a direct call to the hard drive
controller. That kind of thing is very frowned upon in the modern
windows world. M$ wants all your calls to go to their API's, so they
can change them every six months or so.

I agree with the rest of what you are saying. I just got a laptop with
an AMD 64 3000+ cpu and I can't wait till my 64 bit version of SuSE
gets here.

Later.

 

[Ron Martell]

I am having second thoughts as to the efficacy of Windows 2003 server as a mission or business-critical
solution. I assume that it uses NTFS by default, and I am also assuming that this is the cause of my current
woes.

We have an old DOS market research system written in Zortech C (version 2.1 from 1989). It has worked
flawlessly since 1990 when it was released for our various clients' use. They have hammered every aspect of it
over the years, and it has never gone wrong. It was always run under Novell Netware, but recently, we migrated
our office to Windows 2003 Server (SBE). Since then, we have had files intermittently truncated when opened
using fopen with the "a" mode (open for appending and create if it doesn't exist), files in use when they
definitely are not in use, and, just today, the worst of all - a 600KByte file full of respondent details had
its contents replaced by zero (null) bytes, whilst retaining its original size after a simple
fopen(sample,"ab"). What must we do to make our SBE server reliable?

We have tried getting rid of optimistic locking and other caching techniques using the following .reg files :-
------------------------------------------------------------
Client Registry patch (copy and paste into a .REG file if you like) :-

------------------------------------------------------------

Windows Registry Editor Version 5.00



[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VXD\VREDIR]

"DiscardCacheOnOpen"=hex:01

------------------------------------------------------------

2003 Server patch (copy and paste into a .REG file if you like) :-

------------------------------------------------------------

Windows Registry Editor Version 5.00



[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters]

"EnableOpLockForceClose"=dword:00000001

"EnableOplocks"=dword:00000000

"CachedOpenLimit"=dword:00000000

"autodisconnect"=dword:ffffffff

You would probably have better luck posting your request to a
server-related newsgroup such as
microsoft.public.windows.server.general

My opinion is that this problem has nothing to do with the NTFS file
system, and you are not even 100% certain that the disk
drive/partition in question is using NTFS.

That question can be resolved quite easily. On the server open "My
Computer" and right-click on the icon for the drive that contains the
DOS app. Select Properties from the drop-down menu and it will tell
you which file system is in use on that drive.

And if it is using NTFS you might want to consider trying it on a
FAT32 drive/partiton instead.

I suspect that the problem, when the underlying cause is fully
diagnosed, will be an incompatibility of the application program with
an NT based operating system.

A 15 year old business application has lasted far beyond the normal
life expectancy of this type of software and it may be time to
evaluate just how appropriate the software really is to today's
business environment. The world has changed greatly in the past 15
years and there are undoubtedly at least some aspects of this software
which are not really in tune with today's reality.

Good luck




Ron Martell Duncan B.C. Canada
--
Microsoft MVP
On-Line Help Computer Service
http://onlinehelp.bc.ca

"The reason computer chips are so small is computers don't eat much."

 

[Mark Jacobs]

Thanks for your reply. However, you have not explained why this same 16-bit DOS conventional memory .EXE file
works under Novell Netware on XP clients, but not on 2003 server under XP clients. Because it uses only
conventional memory, there is no way it could have clobbered a 600K sample file, filling it with zeroes, when
it is only ever opening this file in append mode. Of course, there are many factors, but as a programmer, I
have tried to pin it down to the lowest common denominator - the fopen statement. This is ANSI C, so it is up
to the underlying OS to *fully* support it. Failing that duty means MS is no longer interested in fully
supporting ANSI C. If that is the case, you will see a mass migration of (real) programmers to Linux boxes.

Sometimes I think that MS are trying to be too clever, and end up overlooking some repercussion of
implementing a new feature. When the error reports start coming in, it is usually too late to rescind the OS
publication, and so it gets whispered about in these newsgroups, but never in the main computing media and
press. Rarely do these issues ever get fixed.
--
Mark Jacobs
DK Computing
http://www.dkcomputing.co.uk
(e-mail address removed)

I am having second thoughts as to the efficacy of Windows 2003 server as a mission or business-critical
solution. I assume that it uses NTFS by default, and I am also assuming that this is the cause of my current
woes.

We have an old DOS market research system written in Zortech C (version 2.1 from 1989). It has worked
flawlessly since 1990 when it was released for our various clients' use. They have hammered every aspect of it
over the years, and it has never gone wrong. It was always run under Novell Netware, but recently, we migrated
our office to Windows 2003 Server (SBE). Since then, we have had files intermittently truncated when opened
using fopen with the "a" mode (open for appending and create if it doesn't exist), files in use when they
definitely are not in use, and, just today, the worst of all - a 600KByte file full of respondent details had
its contents replaced by zero (null) bytes, whilst retaining its original size after a simple
fopen(sample,"ab"). What must we do to make our SBE server reliable?

We have tried getting rid of optimistic locking and other caching techniques using the following .reg files :-
------------------------------------------------------------
Client Registry patch (copy and paste into a .REG file if you like) :-

------------------------------------------------------------

Windows Registry Editor Version 5.00



[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VXD\VREDIR]

"DiscardCacheOnOpen"=hex:01

------------------------------------------------------------

2003 Server patch (copy and paste into a .REG file if you like) :-

------------------------------------------------------------

Windows Registry Editor Version 5.00



[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters]

"EnableOpLockForceClose"=dword:00000001

"EnableOplocks"=dword:00000000

"CachedOpenLimit"=dword:00000000

"autodisconnect"=dword:ffffffff

You would probably have better luck posting your request to a
server-related newsgroup such as
microsoft.public.windows.server.general

My opinion is that this problem has nothing to do with the NTFS file
system, and you are not even 100% certain that the disk
drive/partition in question is using NTFS.

That question can be resolved quite easily. On the server open "My
Computer" and right-click on the icon for the drive that contains the
DOS app. Select Properties from the drop-down menu and it will tell
you which file system is in use on that drive.

And if it is using NTFS you might want to consider trying it on a
FAT32 drive/partiton instead.

I suspect that the problem, when the underlying cause is fully
diagnosed, will be an incompatibility of the application program with
an NT based operating system.

A 15 year old business application has lasted far beyond the normal
life expectancy of this type of software and it may be time to
evaluate just how appropriate the software really is to today's
business environment. The world has changed greatly in the past 15
years and there are undoubtedly at least some aspects of this software
which are not really in tune with today's reality.

Good luck




Ron Martell Duncan B.C. Canada
--
Microsoft MVP
On-Line Help Computer Service
http://onlinehelp.bc.ca

"The reason computer chips are so small is computers don't eat much."