#197 Windows REXXUTIL.DLL Changes

[Jerry Senowitz]

I have made a number of changes to the Windows version of REXXUTIL.DLL to 1) add features to SysGetFileDateTime and SysSetFileDateTime, and, 2) fix a number of problems in SysFileSearch and SysFileTree. The changes have been documented in patches.txt in the patches.zip file.

[Jon Wolfers]

Hi Jerry,

I've had a quick look at your patch and I have to say I'm very impressed (i'm not a C++ coder, so perhaps I impress easily).

I hope that we can find someone on the team to asses these changes and apply as appropriate.

Jon

[Jerry Senowitz]

Jon,

Thanks for the comments!

I have rewritten SysGetFileDateTime to get rid of all occurrences of the -1 return code except for invalid filename. Don't have to worry any longer about whether or not the file is "openable". I have included the changes in patches2.zip. This is a complete replacement for patches.zip. Trying to avoid deltas.

Is there some way to delete "patches.zip"? That way I don't need to worry about which attachment was retrieved.

Jerry

[Erich]

| Is there some way to delete "patches.zip"?
Jerry, I removed patches.zip as requested

[LesK]

I have to question why you think you no longer have to worry about whether the
file is 'openable'? Is there an RFE open to remove that feature?
What happens if the invocation does not use one of the documented access types, which,
I presume would have returned a -1 rc?

[Jerry Senowitz]

Thank you Erich for removing the "patches.zip" file. I didn't see any obvious buttons to click on.

LesK,
Perhaps you should (re)read the description for SysGetFileDateTime in the ooRexx Reference documentation (pgs 542-543). There is no reference to a "feature" that tests "openability" of a file/directory. It only returns a time stamp based on timesel. There is a restriction defined in the 3rd paragraph that discusses the file state before a time stamp can be retrieved. The rewrite removes this restriction under Windows. Now SysGetFileDateTime with a timesel of "W" and SysFileTree with option "L" will produce the same time stamp regardless of the file state. As an example, try to do a SysGetFileDateTime on "pagefile.sys". The current release level ooRexx will produce a -1 Return Code because that file is "unopenable". With the changes I made, you can get the "W", "A", "C" timesels. All error handling remains the same i.e -1 for invalid/not found filename, RC(40) "Incorrect call to routine" for an invalid timesel.

[Rick McGuire]

Jerry, I'm hoping you're still around after all these years. I'm not sure how this fell through the cracks, but since I'm currently working on an extensive cleanup of rexxutil, I thought I should revisit all open issues on SysFileTree(). I'm not sure I understand what you are doing with your SysFileTree patches. Your changes prepend "\?\" to the path, but then then call FindFirstFile using path+4 as the pointer to the path. How does the prefix have any effect? Secondly, all of the documentation I've seen about using that prefix say you need to be using the unicode version of the functions for that prefix to be effective.

[Jerry Senowitz]

Yep, still around, at least for these comments. Should have put a limit for how long I would be willing/able to answer questions (It's been 3+ yrs since I uploaded the patches). My comments below are largely from memory recall, although, did look at the code in the hope it would refresh my memory.

The "\?\" prefix is an indicator that what follows is an "extended path" where the length limit is up to 32767 bytes - 5(prefix and null). I preserved the original path length definition of 260 bytes + 4 bytes for the prefix given most initial filespecs would probably be less than 260 bytes on entry to SysFileTree. Documented in "patches.txt" beginning at @@2072-2117. I chose to support extended path thruout that section of code for simplicity and make adjustments to rpoffset" based on wheither or not filespec was fully qualified -> d:\path\fn.ext. This addressed relative and network path cases also. "rpoffset" can only have only 2 values: 0(line 2086) or 4(line 2084). It was simplier than setting and testing a switch all the time, then, creating a different parameter based on filespec.

Don't know what to say about unicode except that it is not required for "extended path"s to work as implemented in REXXUTIL. Furthermore, oorexx does not support unicode, on the whole (I am aware of the 2 unicode utiities). That would be a serious rewrite. If you do a search on MSDN.COM for extended paths, there is little mentioned about unicode. If you search for extended paths and unicode, you get into a quagmire of info. I did read in one place that Windows API bypasses validation checking and passes the filespec directly to the file system when encountering the extended path prefix.

I did revalidate the sysfiletree changes, and, while my original testing environment no longer exists, my current longest path is 712 bytes. Windows goes to extremes to hide extended paths from the user even though that user may have administrator access. You need to use a program like NTFSAccess to change ownership for those hidden? folders.

[LesK]

Thanks very much for the explanation! Us old VM mainframers sometimes don't "get" some of
the hidden features of a pc.