Files.dir.This never fails

[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")