Detecting directory changes

[John E. Malmberg]

To answer the question about Pathworks using the internal routine.

I do not know.  I do not have access to the Pathworks source as I am not 
on that team.  I work closer to the actual hardware.

Since Pathworks and Advanced server support both VAX and ALPHA, there is 
a good chance that it does not.

Older Pathworks versions did not use a routine like that because part of 
the Microsoft Windows SMB specification allows programs to request a 
notification when a directory changes, and while I am not familiar with 
the latest release of Advanced Server, the earlier ones did not have it.

This causes some Microsoft Windows programs not to work with Pathworks / 
Advanced Server.

And I suspect that if just resurecting a POSIX routine was all that was 
needed to implement it, they would have done in on VAX also.

SAMBA also has this same deficiency, unless they have found a way around 
it in the 3.x branch.


The file system is scheduled for a major overhaul.  I can not give 
details, but any program that makes any assumptions about undocumented 
internal structures such as names of locks may break.  You do want to be 
able to support disks that are larger than a Terabyte, or files that are 
that big don't you?

Parts of the retired POSIX product were used as a basis of the DII COE 
effort, and the DII COE routines that are used for UNIX portability are 
being merged into the base OpenVMS product.  As this is happening, the 
POSIX modules may be removed or stop working.  Or they may continue to 
be used.  This is being decided by the teams involved.


We just recently went through an issue on comp.os.vms with the CSWING 
freeware application that was and still is making invalid assumptions 
about how the file system operates or will operate in the future.  Some 
early programmer apparently got this mis-information from reading the 
source listings, or from trial and error.



Now I have put in requests for features to the file system, like a 64 
bit ino_t type, storing at file close the apparent UNIX size of a record 
oriented file for stat to return, storing the UTC time in addition to 
local time so that stat will run faster.  I have also requested support 
for alternate filenames, to help support ODS-2/ODS-5/ODS-? and 8.3 file 
lookups for applications like Pathworks Advanced Server and SAMBA.


But when it comes time to look at funding and time allocation.  Customer 
requested enhancements get priority over internal requests when all 
other things are equal.

The use of the internal POSIX routine may work in the short term, but it 
should not be considered a permanent solution.

-John
wb8tyw at qsl.network
Personal Opinion Only