Logic Bug about random-access-file-reader HOT 5 CLOSED

Possible solutions could be

1. Store cursor position for each line read for the buffer, so that when a cycleForward/cycleBackward operation is performed, the cursor position stored for the first line could be used in seek.

2. Implement a custom 2 way Queue like data structure, rotating the front and rear indices, essentially simulating the cycleForward and cycleBackward effect.

Explore both solutions

from random-access-file-reader.

Another possibility could be using 2 RandomAccessFile objects instead of one. One for the start of the buffer and another for the end of the buffer.

from random-access-file-reader.

The approach chosen in commit 495ae58 is rather simple, keep a single RandomAccessFile object, instead of trimming \n and \r characters while performing readPreviousLine() or readNextLine(), trim them while displaying, so that we can have an exact count of how many bytes to offset and a flag variable boolean isForwardFacing which tells us whether the cursor is at the start/end of the buffer.

from random-access-file-reader.

As the previously stated method didn't work well enough as can be seen in commit 32c9c09, reverted back to the method using 2 RandomAccessFile objects, moving them parallel to each other with a defined offset (bufferSize).

from random-access-file-reader.

Resolved in commit ecdb01c

from random-access-file-reader.