Files.dir.This never fails

[Robert]

This() is not intended to check for the existence of a directory.

Ok. But there are two things that encourage this false idea:

1 - The existence of the return code res = 2 meaning "location not found"
2 - Many examples where the calling code appears to use "loc = NIL" to test for the existence of a directory.

So, I suggest, we want three things:

1 - Clarify the Docu regarding This. Explain when res = 2 does, and does not, occur.
2 - Correct the calling code that misuses the loc = NIL test.
3 - Add a function to test for a directories' existence. (The code I posted earlier shows how to do this with a 1 line Windows call.)

Code: Select all

MODULE  CasketShlwapiDll ["shlwapi.dll"];
IMPORT  SYSTEM, Win := WinApi;

PROCEDURE  PathIsDirectoryW* (path : Win.PtrWSTR) : Win.BOOL;
END  CasketShlwapiDll.


MODULE  CasketShlwapiUtils;
IMPORT  Shlwapi := CasketShlwapiDll, WinApi;

PROCEDURE  IsDirectory* (path : ARRAY OF CHAR) : BOOLEAN;
  BEGIN
    RETURN  Shlwapi.PathIsDirectoryW (path)  #  WinApi.FALSE
  END  IsDirectory;
END  CasketShlwapiUtils.

[Josef Templ]

Ok. But there are two things that encourage this false idea:

1 - The existence of the return code res = 2 meaning "location not found"
2 - Many examples where the calling code appears to use "loc = NIL" to test for the existence of a directory.

So, I suggest, we want three things:

1 - Clarify the Docu regarding This. Explain when res = 2 does, and does not, occur.
2 - Correct the calling code that misuses the loc = NIL test.
3 - Add a function to test for a directories' existence. (The code I posted earlier shows how to do this with a 1 line Windows call.)

No question that the situation is confusing.
But note that the error code 2 is not listed as a result of This().
There is a global list of error codes for the purpose of
mapping error codes to error messages, for example.
This does not mean that all error codes can occur at all places
where error codes are set.
The docu already lists the error codes that can result from
a particular operation, with maybe a few inaccuracies, I don't know.

- Josef

[DGDanforth]

The current functions for obtaining a locator are inconsistent between the two ways.
Let's clean this up.

(1) If a path is invalid the dir.This and loc.This should return NIL.
There is, however, an alternative.
(2) If the path does not exist it can create the directory and return the locator to it.

A one line windows call does the creation "res := WinApi.CreateDirectoryW(path, NIL);"
That creates all necessary sub directories. Example: If only "C:\" exists then
path = "C:\A\B\C\D\E" will have all those sub directories created.

Now doing that is a "side effect" which is strongly frowned upon. However, it does
satisfy the condition of always (unless the syntax of path is not a valid path form)
returning a non NIL locator.

Something needs to change and it is more than the documentation.

-Doug

[Ivan Denisov]

Doug, directories created only if you register your File.

Also all this discussion is related to HostFiles. There are many possible realizations of Files.

If you want to make Windows directories manipulations better use WinApi. Files.Locator does not designed for this issue and, IMHO, it should not be redesigned.

[Josef Templ]

Doug, directories created only if you register your File.

Also all this discussion is related to HostFiles. There are many possible realizations of Files.

If you want to make Windows directories manipulations better use WinApi. Files.Locator does not designed for this issue and, IMHO, it should not be redesigned.

I agree with Ivan.

This should be a bug fix issue, where the bugs are the inconsistency in the docu
and the bugs in testing the error codes. This can be fixed easily.
It should not be mixed up with introducing new features that
introduce incompatibilities with existing code or inefficiencies.

- Josef

[DGDanforth]

Doug, directories created only if you register your File.

Also all this discussion is related to HostFiles. There are many possible realizations of Files.

If you want to make Windows directories manipulations better use WinApi. Files.Locator does not designed for this issue and, IMHO, it should not be redesigned.

I agree with Ivan.

This should be a bug fix issue, where the bugs are the inconsistency in the docu
and the bugs in testing the error codes. This can be fixed easily.
It should not be mixed up with introducing new features that
introduce incompatibilities with existing code or inefficiencies.

- Josef

Fine.
Let's do as you suggest.
===
In my opinion the Oberon Microsystems design of creating a Locator is bad.
The semantics of "path to locator" should reflect the validity of path, directly,
by returning NIL when path is invalid.

What is our purpose? Is it to maintain the status quo at all costs or is it to
produce a better BlackBox environment?

-Doug
(p.s. you don't need to register a "path" whereas you do for a "file")