Login
Templates, Tools and Utilities
for Clarion Developers
Templates, Tools and Utilities
|
||
|
|
|
Icetips Article
Back to article list
Search Articles
Add Comment
Printer friendly
Direct link
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 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 Today is November 21, 2024, 3:58 am This article has been viewed 35440 times. Google search has resulted in 415 hits on this article since January 25, 2004.
|
|