forums.silverfrost.com

sparge · Joined: 11 Apr 2005 Posts: 371

I'm working on some code I haven't looked at for a while, which uses the Salford function FEXISTS@. It seems (to me) to be behaving somewhat differently to the way it is documented. The problem rang a bell so I searched the forum, and the one reference I can find to this function is here:

http://forums.silverfrost.com/viewtopic.php?t=864

although the focus in this topic is split between apparent problems with both FEXISTS@ and OPEN, and the questions never got resolved.

So, according to the documentation:

"FEXISTS@ returns a logical value which is .TRUE. if the name supplied in PATH is that of a file which does exist, or is a wildcard which matches one file only. It returns .FALSE. if such a file does not exist, or if an error occurs in which case ERROR_CODE returns a non-zero system error code."

My concern is with the case where a file does not exist, when FEXISTS@ returns FALSE (as it should) and an error code of 2 (as I believe it should not). I believe that if a file does not exist, the returns should be FALSE and 0. FALSE and non-zero should be returned only if something goes wrong.

Does something here need to be rectified?

Andy

PaulLaidler · Posted: Tue Dec 15, 2009 1:24 pm Post subject:

I understand your logic but users may already depend on this implementation where the error code provides information about the reason for the failure.

The best I could do would be to provide another function that is implemented in the way you prefer.

sparge · Joined: 11 Apr 2005 Posts: 371

I'm not sure you do understand my logic, then Confused

. There is nothing wrong with using the error code to provide information about the reason for the failure, if there is a failure. My concern is that if the file simply does not exist, there is no failure - so the error code should reflect that, with a value of zero. Currently, when a file does not exist, the function is behaving as if an abnormal condition occurred, with the error code of 2 conveying more information about what that abnormal condition was.

It may be that a file not existing is defined as an abnormal condition, flagged by an error code of 2 - in which case it is only the documentation that needs to be changed, because there is no way to get a return value of FALSE and an error code of 0. The documentation doesn't actually state that FALSE/0 is returned if a file does not exist, but I think it is implied by a misleading comma:

"It returns .FALSE. if such a file does not exist, or if an error occurs in which case ERROR_CODE returns a non-zero system error code."

Implication: it returns FALSE in two circumstances, in the latter of which a non-zero error code is returned (implying that a zero error code is returned in the former circumstance). As opposed to:

"It returns .FALSE. if such a file does not exist or if an error occurs, in which case ERROR_CODE returns a non-zero system error code."

Implication: a return value of FALSE is always coupled with a non-zero error code. Which is what seems to happen.

It may be my inferencing that is faulty rather than the documentation's implication Smile

Andy

PaulLaidler · Posted: Tue Dec 15, 2009 4:56 pm Post subject:

I still reckon that I understand your logic. The fact that a file does not exist is not an error condition - the function has succeeded in its purpose.

Never-the-less the function has been written in this way and all I can do is change the documentation if it is misleading. I do not want to change the way the function behaves unless it is absolutely necessary. Someone, somewhere may have used this odd behaviour to advantage.

sparge · Joined: 11 Apr 2005 Posts: 371

sparge · Joined: 11 Apr 2005 Posts: 371

Busy day on the forums today! Nothing like resurrecting old code to open up new cans of old worms. Now I'm tripping up again over another old issue.

This function FEXISTS@ appears to have changed its behaviour notwithstanding Paul's stating he was not going to. And unfortunately it has not changed in a way to bring it into line with its documented behaviour.

I am, as I was before, using it to check the existence of a path. According to the documentation, it should return TRUE if the path exists, FALSE and an error code of 0 if the path does not exist, and FALSE and an error code not 0 if "an error occurs".

Last time I posted about this, it was returning FALSE and a non-zero error code (2) if the path did not exist. I coded around this.

Now I am running the same old code and it is failing because my code-around is broken. The function now returns FALSE and an error code of 3 instead of 2 if the path does not exist.

So it seems the function got changed anyway, and broke my code. Quite ironic, since the stated reason for not changing it was lest it should break someone else's. Maybe now would be a good time to change it again so it finally behaves in line with the documentation (sigh).

Wilfried Linder · Posted: Thu May 12, 2011 1:29 pm Post subject:

sparge, just a question because it is interesting for me: Why do you use FEXISTS@ and not the standard Fortran function inquire? What are the differences between both functions?

Regards - Wilfried

sparge · Joined: 11 Apr 2005 Posts: 371

Wilfried Linder · Posted: Thu May 12, 2011 1:58 pm Post subject:

Hi Andy, you're right. I just have tested inquire and it really only works for files (like I'm using it) but not for paths.

Thanks and regards - Wilfried

LitusSaxonicum · Posted: Thu May 12, 2011 6:20 pm Post subject:

I think that INQUIRE has to work for files in systems that don't conform to the drive:\directory\subdirectory etc organisation, so the definition does not include that aspect. Moreover, INQUIRE looks at the Fortran qualities of a file as well as whether it exists or not.

I dug out my FTN77 manuals, and they don't have FEXISTS@ detailed, so it is a more recent innovation than 1994! They do have MKDIR@ (which is a useful thing to remember), but not RMDIR@ (I made that up in FTN style from the DOS command). There are a bunch of other rather useful subroutines such as SET_FILE_DATE_TIME_STAMP@, RENAME@, ERASE@, SET_FILE_ATTRIBUTE@, ATTACH@, CURDIR@. I wondered if you would find DIRENT@ or FILES@ of some use? Their error codes are DOS error codes. In my experience, many of the Salford FTN77 functions still work, and with the FTN77 library manual online, can be relatively easily followed up.

In this search I was rather amused by the routines READFA@ and WRITEFA@, which I suspect are the file equivalents of the "invisible box".

Isn't it wise to take Paul up on his 18-month old offer to produce the appropriate directory-testing routine? May I suggest DirEXISTS@ or PathEXISTS@ might be good names? One of its tasks could be to check that the path would be acceptable to GET_FILTERED_FILE@ and routines of that ilk.

Eddie

JohnCampbell · Joined: 16 Feb 2006 Posts: 2615 Location: Sydney

Would it be worth writing a routine, using FILES@, to return the number of files in a directory path ?
It would be interesting to see the error return for a path that does not exist, as I think a path that would exist would return at least 2 files; '..' and '.'
Say Integer*4 Function Count_Files_in_Path (path)
returning num-2 if exists and -1 if does not exist.

FILES@ does require a bit of temporary memory to run, especially if there are a lot of files (20,000 is not uncommon, eg in temporary internet files)

John

PaulLaidler · Posted: Fri May 13, 2011 6:42 am Post subject:

I have added this to my list of things to do.
I plan to have something for you before the next release.

JohnCampbell · Joined: 16 Feb 2006 Posts: 2615 Location: Sydney

Andy,

I'd recomend that you consider the options available and write a routine to detect if a path exists. The options considered include to use:
1) Fortran INQUIRE
2) Get a list of files in path using $FILES@ ( there should be 2 entries in an empty directory)
3) FEXISTS@ may require a review of error states (does it return a 1,2 or 4-byte logical?)
4) DIRENT@, which I have never used

I'd expect that $FILES@ could produce a fairly robust solution.

There may be other issues with network path access and also new directory structures in Windows 7, both of which I have little experience with.

John

Wilfried Linder · Posted: Fri May 13, 2011 8:37 am Post subject:

Just an idea, using John's advise:

JohnCampbell · Joined: 16 Feb 2006 Posts: 2615 Location: Sydney

I cut up my directory sizing program and produced the following attempt.
It gives 2 entries for an empty directory and no entries for a non-existent directory.
It worked for a hidden directory, but would probably give 0 for a directory you do not have the rights to.
You need to check other unusual options.
I look for all files "*.*", but you could modify it for special files if the test is more relevant.
(I hope it is not too big - was too big !)