Clarion 6: Logout and Commit hangs when using long filenames
2004-02-09 -- Randy Rogers
Newsgroups: sv.clarion.bugreports
This article contains a whole thread about LOGOUT/COMMIT issues that
have been reported in Clarion 6.
We have a block of code that executes correctly without a logout/commit
frame.
Addition of the logout/commit around the code gives no errors on logout but
the commit hangs the processor. With fewer files logged out, it is possible
to get it to work correctly, but then not all files are being logged. We
found that by using short filenames/paths we were able to have the
logout/commit work correctly.
Is there a limitation on the combined lengths of the full file/path names?
Is this a problem to do with Long File Names or a buffer limitation of some
sort? Or, some other explanation?
Regards
Randy
Newsgroups: sv.clarion.bugreports
Randy,
Can you put together a small version of the app and DCT that exhibits this
problem? If so we will test it here.
No third party tools. If your app has custom graphic files please include them.
Robert (Softvelocity Support)
Newsgroups: sv.clarion.bugreports
Bob,
This small app and dictionary uses ten files to duplicate the COMMIT
problem. There are three menu items:
1) uses long filenames only
2) uses short filenames only
3) uses 5 long and 5 short filenames
Options 1 and 2 work perfectly, while option three hangs on COMMIT with no
error being posted.
Regards
Randy
Newsgroups: sv.clarion.bugreports
Hi Randy,
> This small app and dictionary uses ten files to duplicate the COMMIT
> problem.
>
Thanks for the test app. It does show a problem with how the TopSpeed
driver handles mixing long file name and short file name directories
when you do not specify a TCF file. The work around to this is to
specify a TCF file explicitly.
I have fixed the situation of mixing long and short file names.
However, this is only a specific instance of a generic problem. If you
have multiple files in a transaction that all use the same TCF file,
but point to that TCF file via different paths, then the COMMIT will
lock up. Eg if you map h: to 'c:\program files', do not explicitly
specify the TCF, and then have one file as 'C:\program
files\myfile.tps' and another as 'h:another.tps', then the commit will
lock up.
Cheers,
SuRF
Newsgroups: sv.clarion.bugreports
SuRF,
Below is a typical file declaration line in an application that has been
locking up for 2 years, when the .EXE is placed in a LFN folder,
Wall FILE,DRIVER('TOPSPEED','/TCF=.\Topspeed.TCF'),PRE(WAL),BINDABLE,THREAD
All of the following tests have failed, IOW it still hangs, and comsumes 95%
of the CPU resources, and during the hang, there is no disk activity.
Wall FILE,DRIVER('TOPSPEED','/TCF=\tsi\Topspeed.TCF'),PRE(WAL),BINDABLE,THREAD
Wall FILE,DRIVER('TOPSPEED','/TCF=c:\tsi\Topspeed.TCF'),PRE(WAL),BINDABLE,THREAD
I replaced ALL of the driver strings in my application when I ran these
tests.
The same application works correctly when run from a non LFN folder.
--
Mark Goldberg
www.tradesmens.com
Newsgroups: sv.clarion.bugreports
Subject: Re: LOGOUT/COMMIT hangs when Long File Names Used
New details:
My tests from 2 years ago (when I first reported this bug), showed that some
machines needed to save SHORTPATH and others needed the LONGPATH. Today I
figured out which one to use to avoid the hang.
if COMMAND('0') shows a LFN then use LongPath()
if COMMAND('0') shows the 8.3 version of an LFN or a true short path, then
use SHORTPATH() (or just PATH())
I am still unable to create a small test project that reproduces this bug,
despite significant efforts to do so.
I will be out of town for the next few days ...
--
Mark Goldberg
www.tradesmens.com
Newsgroups: sv.clarion.bugreports
> I have fixed the situation of mixing long and short file names.
> However, this is only a specific instance of a generic problem. If you
> have multiple files in a transaction that all use the same TCF file,
> but point to that TCF file via different paths, then the COMMIT will
> lock up. Eg if you map h: to 'c:\program files', do not explicitly
> specify the TCF, and then have one file as 'C:\program
> files\myfile.tps' and another as 'h:another.tps', then the commit will
> lock up.
SuRF
Although this may sound awfully basic, I've never been quite sure how to
do that.
The docs give the syntax:
[TCFPath =] SEND(file, 'TCF [ = filename ]' )
where the path is returned not set. Are you suppose to use full path with
the 'filename'?
Is there a quick way to set it for all files rather than one by one and risk
leaving one out?
What is the best way to specifiy a TCF file explicitly when the path to data
is not know at compile time for a large dictionary?
Thanks,
Jim Kane
Newsgroups: sv.clarion.bugreports
In article , Jim kane wrote:
> [TCFPath =] SEND(file, 'TCF [ = filename ]' )
> where the path is returned not set. Are you suppose to use full path with
> the 'filename'?
> Is there a quick way to set it for all files rather than one by one and risk
> leaving one out?
> What is the best way to specifiy a TCF file explicitly when the path to data
> is not know at compile time for a large dictionary?
>
We have used "SEND(somefilename, 'TCF=appname' )" to set the TCF file for a
long time, and I was under the impression that once it was set for one file it
would be used for all.
It seems to have been working...
Newsgroups: sv.clarion.bugreports
John:
That is one of the things I'm hoping to get clarified - whether is needs
to be set for each file or not.
jim kane
Newsgroups: sv.clarion.bugreports
We set the TCF by reading it first then changing it if its not what we expect.
We've found you only need to set it on one file and then it appears for all others.
Dave
Newsgroups: sv.clarion.bugreports
Subject: Re: LOGOUT/COMMIT hangs when Long File Names Used
Hi John,
> It seems to have been working...
>
The TCF file is only ever used for file recovery. Even then it is only used when
a crash happens in the middle of a COMMIT or ROLLBACK statement. So you have
probably never needed it.
Cheers,
SuRF
Newsgroups: sv.clarion.bugreports
Hi Jim,
> Is there a quick way to set it for all files rather than one by one and risk
> leaving one out?
>
If you define all your file as
TPSDriverString STRING(30)
MyFile FILE,DRIVER('TopSpeed', TPSDriverString)...
And then in the initialisation of the program do
TPSDriverString = '/TCF=' & what I want to set it to
Then you will guarantee it being set for all files.
Cheers,
SuRF
Scott later commented to add that this is only needed once, not for each file.
(Arnor)
Newsgroups: sv.clarion.bugreports
Hi Randy,
This silly little program shows LOGOUT/COMMIT working with long file
names. So we will need more information.
program
map
check(string)
.
f file,driver('topspeed'),name('a long file name'),create
r record
fld1 string(10)
..
code
create(f)
open(f)
logout(1, f)
check('logout')
add(f)
add(f)
add(f)
commit()
check('commit')
message('done')
check procedure(string msg)
code
if errorcode()
halt(1, msg & ' caused error: ' & errorcode() & ' : ' & error())
end
Cheers,
SuRF
Newsgroups: sv.clarion.bugreports
Robert/Scott,
We will put together a sample for you a bit later today.
Regards
Randy
Newsgroups: sv.clarion.bugreports
Hi Scott,
I've seen something like this in C5 and I'm including an old post from Mark
Goldberg reporting it in C55.
My experience is that the problem centers around a long file name path, not a
long file name. Also, this problem has never happed on a Win 98 box. It is
always on a W2K machine. I've not personally seen it on XP, since we changed
our program to use ShortPath before XP came out.
I never attempted to reproduce with a small program. Unfortunately, the code
where it happened in our application was large and complex. I resolved the
problem by changing all of the my SetPath() statements to use ShortPath() on
the path value first. After doing this the issue disappeared.
Sorry I don't have more info.
Rick Martin
Sharpe Software, Inc
Mark Goldbergs post from 24 Apr 2002 in the softvelocity.products.c55ee.bugs newsgroup.
sav:path string(255)
code
sav:path = path()
!do some significant code with danger of path changing
sav:path = longpath(sav:path) !<=== the culprit
setpath( sav:path)
The above code (extracted from a much larger system) causes failures on SOME
machines. What is interesting is if I remove the sav:path =
longpath(sav:path) code then all is well. Note: a problem machine will fail
consistently.
By fail, I mean that CheckOpen() fails when it attempts to open files.
Debugging shows that the path appears to be correct, but the path changes
from "C:\Progra~1\estimate" to "C:\Program Files\Estimate" when the path
shows the shortpath version, then all is well.
Furthermore, I've found that after the SetPath("C:\Program Files\estimate")
that
a transaction on TPS files, hangs on COMMIT taking 99+% of the CPU (on a
Win2000 machine).
disclaimer: As I have yet to create a small sample program for this bug, it
is possible that there are larger issues involved.
Tested using: CW55eeF, 32 Bit
--
www.Tradesmens.com
Mark Goldberg
Newsgroups: sv.clarion.bugreports
Thanks Rick for finding and re-posting my observations.
I've been searching for it, and have been unable to find it.
We are still experiencing this problem.
We have been moving our clients installation folder out of "program files"
as a work around.
I can reproduce the bug on my XP Pro SP1, fully patched machine.
Randy recently mentioned that he felt the issue had to do with a mix of LFN
and SFN. I think that there are other ways to trigger the problem too, I
just haven't been able to track them down.
In every case, I can only reproduce the bug, if the .EXE is in a LFN folder.
Granted I'm not using a name attribute on my .TPS files, so they're trying
to run in the current folder.
--
Mark Goldberg
www.tradesmens.com
Newsgroups: sv.clarion.bugreports
Hi Mark,
>Thanks Rick for finding and re-posting my observations.
>I've been searching for it, and have been unable to find it.
You tend to remember when someone describes a problem that has driven you nuts.
>Randy recently mentioned that he felt the issue had to do with a mix of LFN
>and SFN. I think that there are other ways to trigger the problem too, I
>just haven't been able to track them down.
In our case, I know there are no long file names in our dictionary. The code
that originally caused this problem for us was using FileDialog. We stored the
user previous selection and changed to that path before calling FileDialog for
them to pick a file. After the call we switched paths back to our application
folder. If the saved paths were long file names and the system was W2k, a
logout commit later in the process would lock the system. Like I said, forcing
the restore path to always use ShortPath appeared to solve the problem.
Are you still seeing this in C6? If so, I'll try to put together a sample program.
Thanks,
Rick Martin
Sharpe Software, Inc
Printed November 21, 2024, 10:51 am
This article has been viewed/printed 35441 times.
Google search
has resulted in 415 hits on this article since January 25, 2004.
|