Problem with File on server

[sobak]

I'm having a strange problem with a file on my NetWare 4.11 server. Windows seems to loose the location of a file on the server but I know it's there. I can not find the file through Windows Explorer or if I open a DOS prompt and use a wildcard. But if I open a DOS prompt and search directly for the file name (01SSG3N9.dgn) then I get a directory listing of the file. If you try to copy a file into that directory then you get an error that the file already exists but you can not overwrite it. I've gone into ConsoleOne and NWAdmin to look for the file and it does not display there either. Thinking it was a client issue, I've updated my client to the newest 4.83SP1 version and I still can not find the file without doing a direct search for it. I've ran DSRepair and Vrepair on the server and it doesn't seem to fix the problem. The only way I've been able to fix the problem is

Copy the file through DOS down to my local workstation.
delete the file name (01SSG3N9.dgn).
Copy the file back to the location.

This is only happening to certain files in a particular directory I have over 230 Gigs of information on this server with people hitting it every day dumping data on it. I would think if it was a server issue then I would see it with other files as well.

My server is fully patched with SP9a and the workstation is running Windows 2000.

Any help on this matter would be appreciated since I am at the end of my rope.

david e
*end users are just like computers, some you can work with...others just need a simple reBOOTing to fix their problems.*

 

[TheLad]

Have you run a Full Unattended DSREPAIR? -----------------------------------------------------
"It's true, its damn true!"
-----------------------------------------------------

 

[sobak]

Yes, that was one of my very first steps to see if there was any corruption.

A little more information...

When I copy/move the file down to the local workstation and attempt to open the file, the file is actually the file that would come below the existing one. For example.....

If I copy file 01SSG3N9.dgn down to the local workstation and open it, the file is actually 01SSG3N10.DGN. When I attempted to open the actual 01SSG3N10.DNG on the server I receive an error "file not found" if I go back to the file then the entire 01SSG3N10.DNG file has been deleted off the server. If I open 01SSG3N9.dgn it is actually 01SSG3N10.dgn.

This is the first time that I've ran into a problem like this in my 15 years in the IT industry. I don't believe this is a Novell problem but when the file disappears from windows and the only way you can find it in DOS is to do a directory on the specific file then that leads me to believe that the servers FAT table is not being updated properly.

In the past three days I've ran four Vrepairs and none of them came up with errors so that leads me to believe that the mirror copy of the fat is actually correct. Also the problem is only happening on one project (one directory) and I have about 5000 projects being updated on a daily basis. Unfortunately since I’ve identified there actually is a problem I now have people jumping on the bandwagon and associating their problems as being caused by this. Of course this clouds managements view and I'm trying to stop this from escalating into a full-fledged witch-hunt.

A little more background on this .DGN files are Microstation Design files, we are an architectural firm and work with Microstation instead of AutoCad. I believe this is actually a Microstation issue but I don’t know how that program could screw up a file so bad on the server that Windows or DOS looses it’s location and a Vrepair doesn’t catch the problem.

Help on this matter would GREATLY be appreciated.


david e
*end users are just like computers, some you can work with...others just need a simple reBOOTing to fix their problems.*

 

[TheLad]

You're not suffering from the old DOS 8.3 problem are you? The first file you mention - 01SSG3N9.dgn - falls into the 8.3 naming convention. The second file - 01SSG3N10.dgn - is 9.3 which when viewed in DOS would be a different truncated 8.3 name. -----------------------------------------------------
"It's true, its damn true!"
-----------------------------------------------------

 

[sobak]

Originally I thought it was a name space issue, that is what prompted running VRepair. I am also under the impression that once you load the long name space and add it to the volume 8.3 goes out the window and all files are treated as long file names (I may be wrong in this thinking but that’s how I understand it).

I have other long file names (trust me my users can come up with some winners) on the server and those don't seem affected.

The problem that I have with this is that the project came from our Miami office and moved to one of my local offices. Once the files were back here is when we started seeing this problem. We thought we had it fixed but after the files were moved from one server to another the problem has reappeared.
david e
*end users are just like computers, some you can work with...others just need a simple reBOOTing to fix their problems.*

 

[TheLad]

You have to bear in mind that accessing files from DOS will still use the 8.3 file names as DOS is not clever. If you use a DOS prompt from Windows, you will be able to do a DIR /X which will show you the long filename with it's 8.3 equivalent.

Every long filename has an 8.3 equivalent. -----------------------------------------------------
"It's true, its damn true!"
-----------------------------------------------------

 

[sobak]

Cool, I was not aware of the /X command, I will have to try that the next time that will also come in handy for troubleshooting.

As far as this relates to the issue at hand I never attempted to do a directory from DOS on the long file name. Once I received the "file not found" error all I did was go to Explorer and look for it. I didn't bother looking for it since the old 8.3 file name was the contents of the 9.3 file. I guess I (do I dare say) assumed the message was correct and in fact the file was deleted off the server.

Now I'm wondering is there an update LONG.NAM that wasn't included in SP9a? david e
*end users are just like computers, some you can work with...others just need a simple reBOOTing to fix their problems.*

 

[MarkhP]

Are you running MIXMODFX.NLM on the server. If not, you may want to load it and then try again. We use Microstation here and that is the only thing extra I can think of that we have loaded. It shows long names under DOS as 123456~1.xxx instead of 12345678.xxx as default Novell does.

*You may have to move the file out of the directory and then put it back again so that it is written with the correct 8.3 filename e.g 01SSG3N9.dgn

Other than that, If you run NDIR /L, does the long filename (OS/2) name match the 8.3 name?

 

[sobak]

Mark,

I've corrected the last issue but it's just a matter of time until it happens again.

We talked to Bentley yesterday and they basically told me that it was a corrupt directory, no answers there. My argument to Bentley's reasoning is that if it was indeed a corrupt directory then why doesn't VRepair catch it and attempt to fix it during it's run? Unless I'm placing too much faith in VRepair but I've had it fix many problems with corruption on my servers.

Once this happens again I will do a much more extensive search on the matter. I will update this thread when I'm able to do those checks.

Thanks for your help....

david e
*end users are just like computers, some you can work with...others just need a simple reBOOTing to fix their problems.*