Has anyone else noticed that CfsFileDescriptor>>#size returns incorrect values when the actual file size is > 0xFFFFFFFF? The #size method calls #lseek:whence: which prepares the proper parameters for the Windows SetFilePointer call but it seems to neglect actually using the high order 32 bits when the call returns. If I make the change to #lseek:whence: to check for high order 32 bits, it seems to return proper values. Currently the call returns:
^result negative
ifTrue: [CfsError new errno: EINVAL]
ifFalse: [result]]
without checking to see if Windows set anything in the high order 32 bits. If I change it to:
^result negative
ifTrue: [CfsError new errno: EINVAL]
ifFalse: [
((highOffset uint32At: 0) > 0)
ifTrue: [ OSInt64 new uint64At: 0 put: result; uint32At: 4 put: (highOffset uint32At: 0); uint64At: 0 ]
ifFalse: [ result ] ]]
to check for the high order bits, it seems to return proper values for files bigger than 16rFFFFFFFF (4294967295).
I've tested this on 32 bit and 64 bit systems and with versions up to 8.6. All tests returned incorrect file sizes without the above change.
--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
[hidden email].
To post to this group, send email to
[hidden email].
Visit this group at
http://groups.google.com/group/va-smalltalk.
For more options, visit
https://groups.google.com/groups/opt_out.
Locked
