As noted in bug report 2802679, the size of a file as returned by function SysFileTree is modulo 4 gigabytes (4,294,967,296).
I suggest that SysFileTree be changed so that it return the correct file size when possible, which seems to be a number up to 11 digits long (99,999,999,999) in the SysFileTree's fixed column output. Otherwise, it should return an overflow indication (e.g., "overflow") in the size field since it's better to have calling programs which depend on the number to overtly fail than allow them to apparently succeed but with incorrect results.
A second enhancement would be to add another option letter in the 3rd argument which would specify that a new format of results be returned which includes room for much larger file sizes. That would also provide the opportunity to add more information to the output, such as file access rights.
Or is there some portable, modern way to scan directories, such as Windows-only .OleObject~new('Scripting.FileSystemObject') which walks directories? In that case, I'd still suggest the "overflow" indicator mentioned above be implemented.
Doug Lorch
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'd really prefer not to enhance SysFileTree, but introduce a more object oriented approach to things. I quite like the model used in Java with the File class, which avoids the parsing issues entirely by making the individual pieces of information just method calls. Much easier to expand in the future, and also much more flexible.
I started hacking together one of these thinking maybe it would ship as a sample app in 4.0 and "promoted" in a later release, but this never really got far enough along to be useful. One of many things I'd like to get completed in the next turn of the crank.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2009-06-09
Sounds good, although I'd still like SysFileTree to never return false information.
It's been a long time since I used Java's File object, but I recall it being nice. The Windows-only .OleObject~new('Scripting.FileSystemObject') also works well, so I hope the possible new class is the best of both.
Doug Lorch
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I totally agree with Rick. A more object-oriented approach is needed in order to prevent these kinds of problems in the future. A File object is the way to go with the function returning an array of File objects that match a search criteria.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As noted in bug report 2802679, the size of a file as returned by function SysFileTree is modulo 4 gigabytes (4,294,967,296).
I suggest that SysFileTree be changed so that it return the correct file size when possible, which seems to be a number up to 11 digits long (99,999,999,999) in the SysFileTree's fixed column output. Otherwise, it should return an overflow indication (e.g., "overflow") in the size field since it's better to have calling programs which depend on the number to overtly fail than allow them to apparently succeed but with incorrect results.
A second enhancement would be to add another option letter in the 3rd argument which would specify that a new format of results be returned which includes room for much larger file sizes. That would also provide the opportunity to add more information to the output, such as file access rights.
Or is there some portable, modern way to scan directories, such as Windows-only .OleObject~new('Scripting.FileSystemObject') which walks directories? In that case, I'd still suggest the "overflow" indicator mentioned above be implemented.
Doug Lorch
I'd really prefer not to enhance SysFileTree, but introduce a more object oriented approach to things. I quite like the model used in Java with the File class, which avoids the parsing issues entirely by making the individual pieces of information just method calls. Much easier to expand in the future, and also much more flexible.
I started hacking together one of these thinking maybe it would ship as a sample app in 4.0 and "promoted" in a later release, but this never really got far enough along to be useful. One of many things I'd like to get completed in the next turn of the crank.
Sounds good, although I'd still like SysFileTree to never return false information.
It's been a long time since I used Java's File object, but I recall it being nice. The Windows-only .OleObject~new('Scripting.FileSystemObject') also works well, so I hope the possible new class is the best of both.
Doug Lorch
I totally agree with Rick. A more object-oriented approach is needed in order to prevent these kinds of problems in the future. A File object is the way to go with the function returning an array of File objects that match a search criteria.