issue with ddefine on win2k3

[Brian K. White]

----- Original Message ----- 
From: "Jay R. Ashworth" <jra at baylink.com>
To: <filepro-list at lists.celestial.com>
Sent: Monday, May 21, 2007 4:55 PM
Subject: Re: issue with ddefine on win2k3


> On Mon, May 21, 2007 at 04:30:28PM -0400, Fairlight wrote:
>> I don't get this.
>>
>> I have some existing files in f:/filepro on a Win2K3 system.  I can go 
>> into
>> them with dclerk, I can go into them with ddefine.
>>
>> Using the same exact env vars (I'm coming from the same menu), I get the
>> following when trying to create a new file:
>>
>> *** A System Error Has Occurred ***
>>
>> Cannot open file.
>> //filepro/test/map: Error Number -1
>> Windows error #53
>> The network path was not found.
>>
>>
>> ...Yes, and of course it doesn't exist -yet-, ddefine is supposed to 
>> create
>> it.  If it's complaining about the directory not existing, well, it was
>> supposed to take care of that as well (it isn't...the directory doesn't
>> exist), and it's also complaining about the wrong thing, then.
>
> I strongly suspect that you have a PFvar set wrong; "//" is special to
> UNC pathnames, and I don't expect to see it there.  Is filepro in the
> root of the drive?  (I believe you said las tweek that you usually put
> a \appl in.  And should those be forward slashes?  :-)
>
>> Now why would I be able to perfectly well get into existing databases but
>> not create a new one?  Further, if I manually make the directory, I see 
>> it
>> show up in the list of files, but I get the same error.  So I guess that
>> answers the question of whether or not it's complaining about the map or
>> directory...except it's still supposed to be handling these things.  I
>> tried creating a 0 length map just so the file exists, it then complains
>> about it being "no or invalid map", which I suppose is sensible.  I just
>> don't see why it's seeing this stuff but not performing steps it should 
>> be.
>>
>> It shouldn't be permissions issues of any sort...I'm in as administrator.
>
> Hmmm...
>
>> Windows 2003 Server, fP 5.0.14DN9
>>
>> PFDSK=f
>> PFDATA=/
>> PFDIR=
>>
>> Actual database directory:  f:/filepro
>
> Ok, well, that answers my first question.  I still think this might
> have to do with the semantics of "//", though.  Well, "\\", actually, I
> guess.
>
> I'm never clear on when DOS fp will translat pathname slashes and when
> it won't, either...

I think fp never translates anything. Merely it's up to each windows 
executable (or library function from some dll) to understand / or not.
Some programs understand / and \. And fp understands both. Some apps 
understand internally / but ususally the shell or the app also thinks / are 
command line switches unless you take pains to ensure they don't, like 
quoting, or there might not be any means to avoid having the /'s interpreted 
as switches. Maybe fp understands / just fine in all places within fp, but 
then when fp hands a string to some windows api function or external 
command, some of them are ok with / and some are not.

So it's a case of, / is so much easier to deal with that it's worth trying 
to use in every new place where you need to handle pathnames, and only if it 
fails go through the bother of using \. Something like the PF variables that 
you know are central to the system and will be used in countless places in 
countless ways, you have to use \ because thats what windows really uses 
underneath it all, and so thats what is garunteed to work. Random new system 
and menu commands you just have to try /'s and see if you luck out and it 
works in that particular context.

Brian K. White    brian at aljex.com    http://www.myspace.com/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!