I am having a problem where manually setting NetFileDir to an UNC path will result in a pdoxusrs.lck that contains driveletter + path syntax, meaning that other remote clients can't access those tables, cause the path to NetFileDir doesn't match.

The software is running at a lot of customers, and it is the first time that this problem occurs, in all other cases, the UNC name gets written unmodified to PDOXUSRS.LCK as expected.

Example:
On the server, the application and its datadir are located in C:\Programme\OurApp\Data
the directory "OurApp" is made available as a share called "OurShare" that can be accessed as \\Server\OurShare.

The appplication on the server sets
* Session.NetFileDir := '\\Server\OurShare\Data';
before opening the tables (definitely in UNC syntax).
At this particular customer, it creates a PDOXUSRS.LCK in c:\Programme\OurApp\Data which references
* C:\Programme\OurApp\Data
instead of
* \\Server\OurShare\Data

This different path syntax prevents remote clients from accessing the tables, having "c:\Programme" in PDOXUSRS.LCK is absolutely unwanted, but on the customers box, there seems to be no way to get around this path munging.

So we did another test, letting the server mount its own share as "X:", so the application will execute following command
* Session.NetFileDir := 'X:\Data';
But when opening tables, the PDOXUSRS.LCK once again says "C:\Programme\OurApp\Data".


BDE Setup:
We deleted the .net and .lck files before each attempt, so we are sure they really belong to our app.
We also looked into the BDE settings, NetFileDir is set to 'C:\' there, so even if setting Session.NetFileDir would not have taken place for whatever reason, the resulting .LCK file should point to C:\ but never to C:\Programme\...
LocalShare is set to TRUE on both machines, all settings from BDE control panel are identical to ours, so this shouldn't be caused by a wrong BDE config.

I already followed the tips from the "NET DIR troubles" thread at http://www.dbforums.com/t1084168.html:
- 1. http://www.thedbcommunity.com/faq/13.htm
--> contains no new information for me
- 2. Oplocks
--> I doubt this can have anything to to with our problem, and testing it showed no difference
- 3. n/a
--> fine
- 4. LOCALSHARE = TRUE
--> already done
- 5. Disk caching should be disabled
--> Can you imagine the laughter when I asked the customer to disable write cache on a file server? That is no option, I can't convince him (not even me) that this can cause the path munging. Remember, I am not having problems with data integrity.

The only difference to us and all other customers is that they use Windows 2003 as Server, all other use either XP, 2K and a handfull still NT4.
Does anyone know such path munging effects from Windows 2003 (or maybe other situations)?
Has anybody an idea how this can be worked around?

Sorry, my fault. I overlooked that this was a result of falling back to default values when the shared directory had insufficient access rights.