midfde
asked on
Why does "DIR \\<hostname>\<share>" returns wrong result?
Please see command line session below and help to understand what is going on. How can this be that dir... <share> and dir <path> display different results. Many applications that have been working for years all of a sudden failed because their UNC is not valid any more after yesterday Sunday's restart.
Any ideas?
Any ideas?
c:\1>hostname
FDEFS1
c:\1>net share|findstr -i pacrat
PACRAT C:\FDEAppDATA\PACRAT
c:\1>dir C:\FDEAppDATA\PACRAT|findstr "File(s) Dir(s)"
28 File(s) 74,780,829 bytes
55 Dir(s) 25,495,023,616 bytes free
c:\1>dir \\fdefs1\pacrat|findstr "File(s) Dir(s)"
71 File(s) 19,761,307 bytes
25 Dir(s) 16,988,098,560 bytes free
c:\1>ver
Microsoft Windows [Version 5.2.3790]
Windows Sever 2003; has been working fine for years.ASKER
Yes, PING displays
Ping statistics for 10.201.12.64:
In fact I know that "dir \\fdefs1\pacrat" displays the contents of unrelated folder:
Ping statistics for 10.201.12.64:
In fact I know that "dir \\fdefs1\pacrat" displays the contents of unrelated folder:
c:\1>dir C:\FDEAppDATA\Intranet\FDEDropBox\PACRAT\ExpertAnalysis|findstr "File(s) Dir(s)"
71 File(s) 19,761,307 bytes
25 Dir(s) 25,494,687,744 bytes free
Interesting.
Check the properties of the share itself in Computer Manager?
Check the properties of the share itself in Computer Manager?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
The error has been diagnosed, and it was passed to IT management.
So what was it and why have you accepted the last post?
ASKER
After
I realized that
1) I located an error and
2) It's our IT management that is better to handle this mishap (so do they)
c:\1>nslookup fdefs1
*** Can't find server name for address 10.201.12.51: Non-existent domain
Server: UnKnown
Address: 10.201.12.51
Name: fdefs1.dmz.facilitydynamics.com
Address: 10.201.12.64
I realized that
1) I located an error and
2) It's our IT management that is better to handle this mishap (so do they)
so why have you accepted http:#37518424 as the solution when it clearly has nothing to do with it.
ASKER
I accepted it because I was satisfied after I applied the tool recommended in this message. Roughly, I understood it was not my problem as a developer. I thank you, demazter for your input, but... questions are nevertheless not (necessarily) answers.
Have you checked file system integrity?
To me, the behavior points toward symbolic link, not necessarily UNC, problems.
But that's just intuition; can't really state a logical reason why.
To me, the behavior points toward symbolic link, not necessarily UNC, problems.
But that's just intuition; can't really state a logical reason why.
ASKER
System integrity? Sounds lovely! What is it after all? Is it something verifiable?
if you PING FDEFS1 does it return the local IP address?