I have been working on & off on the Windows version of REXXUTIL.cpp 4.2.0 and have made a number of changes to it to fix problems in SysFileSearch(ticket 915) and SysFileTree(3 unticketed). Also made feature updates to SysGetFileDateTime and SysSetFileDateTime.
When looking at the "Contributions" web page it references "context diff (patch file)". Is there a specific program to be used to generate the diff file or can "FC" be used? FC wraps lines that are longer than 208 bytes and assigns a new line number to the wrapped line. Therefore, line numbers can be off with respect to reality.
I assume then that I should follow the instructions provided in the "Contributions" web page.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry but I can not answer your specific question about the diff file generator.
But can you elaborate on the 3 unticketed problems you fixed in SysFileTree?
Andre
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One problem is that when the file size is > 4gb the size is incorrect because Windows splits the size into 2 DWORDs and SysFileTree only looks at the low DWORD. This turns out to be the remainder after division by 4gb.
The other 2 problems have to do with recursion. I was trying to reconcile differences between Regina's output and ooRexx's and was missing, in my scenerio, 91 subdirectories that Regina found and ooRexx did not. One of the problems was it always passed the pointer to a static field where the original path was saved even though it realized that it needed a new longer field to build the next path. I recovered 25 directories with that fix. The other fix had to do with the path increasing in size to > 257 bytes. The global search characters that were appended to the path forced the path to 260 bytes or greater. Fixing this problem got back the 66 missing subdirectories.
The above info is at a C++ level and not ooRexx. I am running a Windows 7 64 bit system with 12 gb of storage and I learned that Windows creates some long subdirectory chains. When I tried to use SysFileTree with the 'S' option, I wasn't getting information I should have had.
Jerry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks. I am aware of the SysFileTree issue with files > 4GB and had opened ticket #1318 for that some time ago.
Recently some comments were added about fixing this (yes/no) that you may want to read in the bug report.
Andre
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm going to avoid commenting in ticket #1318. This issue has been around probably since the ooRexx development team inherited the code from IBM. I just looked at the source code for V3.11(2006) and it exists there as well. In 2012 (went back though my old emails) I brought this to the attention of the developer working on a SysFileTree stability issue I encountered. He responded with an entry from the developer's forum going back to 2010 that this was a restriction because to do the job right, the length of the stem variable needed to contain the data would need to be increased. There were/are an untold number of applications out in the world that parsed the stem variable by column and not "word" and "subword". They would need to be fixed causing many irate customers.
To net this out, there are 2 problems here. The accuracy of the file size when files are greater than 4gb and if this were fixed, the impact to existing programs. My solution/fix attempts to contain the file size where the 'ones' position of file size remains in the same column that it is in today up to 100gb-1. Not too many files > 100gb, at least under windows. Directory sizes are always 0, although I've seen programs that sum up all the files in a directory and call that the directory size.
If you are looking for file size accuracy, I suggest Regina (also available on sourceforge.net). The REGUTIL.dll has been around for a long time and it seems stable for SysFileTree. I use it as a benchmark to validate ooRexx output.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Would it be a bad idea to create two new calls (SysFileSearch2 and SysFileTree2) that conform to the updated limits, and leave the original SysFileSearch and SysFileTree untouched? That way everybody goes home happy, no existing code breaks, and those who use the origial calls can migrate to the new calls when it seems appropriate. Rather than break backward compatibility, I believe this is a (fairly) common practice...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have been working on & off on the Windows version of REXXUTIL.cpp 4.2.0 and have made a number of changes to it to fix problems in SysFileSearch(ticket 915) and SysFileTree(3 unticketed). Also made feature updates to SysGetFileDateTime and SysSetFileDateTime.
When looking at the "Contributions" web page it references "context diff (patch file)". Is there a specific program to be used to generate the diff file or can "FC" be used? FC wraps lines that are longer than 208 bytes and assigns a new line number to the wrapped line. Therefore, line numbers can be off with respect to reality.
I assume then that I should follow the instructions provided in the "Contributions" web page.
Jerry,
Sorry but I can not answer your specific question about the diff file generator.
But can you elaborate on the 3 unticketed problems you fixed in SysFileTree?
Andre
Andre,
One problem is that when the file size is > 4gb the size is incorrect because Windows splits the size into 2 DWORDs and SysFileTree only looks at the low DWORD. This turns out to be the remainder after division by 4gb.
The other 2 problems have to do with recursion. I was trying to reconcile differences between Regina's output and ooRexx's and was missing, in my scenerio, 91 subdirectories that Regina found and ooRexx did not. One of the problems was it always passed the pointer to a static field where the original path was saved even though it realized that it needed a new longer field to build the next path. I recovered 25 directories with that fix. The other fix had to do with the path increasing in size to > 257 bytes. The global search characters that were appended to the path forced the path to 260 bytes or greater. Fixing this problem got back the 66 missing subdirectories.
The above info is at a C++ level and not ooRexx. I am running a Windows 7 64 bit system with 12 gb of storage and I learned that Windows creates some long subdirectory chains. When I tried to use SysFileTree with the 'S' option, I wasn't getting information I should have had.
Jerry
Jerry,
Thanks. I am aware of the SysFileTree issue with files > 4GB and had opened ticket #1318 for that some time ago.
Recently some comments were added about fixing this (yes/no) that you may want to read in the bug report.
Andre
Andre,
I'm going to avoid commenting in ticket #1318. This issue has been around probably since the ooRexx development team inherited the code from IBM. I just looked at the source code for V3.11(2006) and it exists there as well. In 2012 (went back though my old emails) I brought this to the attention of the developer working on a SysFileTree stability issue I encountered. He responded with an entry from the developer's forum going back to 2010 that this was a restriction because to do the job right, the length of the stem variable needed to contain the data would need to be increased. There were/are an untold number of applications out in the world that parsed the stem variable by column and not "word" and "subword". They would need to be fixed causing many irate customers.
To net this out, there are 2 problems here. The accuracy of the file size when files are greater than 4gb and if this were fixed, the impact to existing programs. My solution/fix attempts to contain the file size where the 'ones' position of file size remains in the same column that it is in today up to 100gb-1. Not too many files > 100gb, at least under windows. Directory sizes are always 0, although I've seen programs that sum up all the files in a directory and call that the directory size.
If you are looking for file size accuracy, I suggest Regina (also available on sourceforge.net). The REGUTIL.dll has been around for a long time and it seems stable for SysFileTree. I use it as a benchmark to validate ooRexx output.
Andre,
Would it be a bad idea to create two new calls (SysFileSearch2 and SysFileTree2) that conform to the updated limits, and leave the original SysFileSearch and SysFileTree untouched? That way everybody goes home happy, no existing code breaks, and those who use the origial calls can migrate to the new calls when it seems appropriate. Rather than break backward compatibility, I believe this is a (fairly) common practice...
As suggested in bug 1318, I think it would be better to maintain compatibility with Regina
and add an 'H' (huge) option.
Found the answer to my original question.