Re: NTFS - Is it reliable?
From: Mark Jacobs (markjremovethisspuriousantispamstuff_at_critical.co.uk)
Date: 05/07/04
- Next message: Marsvin: "Restoring system to earlier point"
- Previous message: MJM: "Re: System Restore"
- In reply to: Ron Martell: "Re: NTFS - Is it reliable?"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 7 May 2004 10:34:34 +0100
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 markj@criticalremovethisspuriousantispamstuff.co.uk "Ron Martell" <ron@onlinehelp.bc.ca> wrote in message news:qa7l90donsmj67eoudv43ns5gjfuvgv9pe@4ax.com... > "Mark Jacobs" <markjremovethisspuriousantispamstuff@critical.co.uk> > wrote: > > >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 > > > >------------------------------------------------------------ > > > >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? > > 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."
- Next message: Marsvin: "Restoring system to earlier point"
- Previous message: MJM: "Re: System Restore"
- In reply to: Ron Martell: "Re: NTFS - Is it reliable?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
Loading
