Let's apply some flip-thinking to this challenge.
Whether the file with unknown contents has 90,000 or 1,500,000 lines, the progress bar in any case cannot possibly display the distinction between, for example, lines 67,000 and 67,001 on the screen. Why would you use such a detailed approach, like Microsoft with a file copy, spend a lot of resources (time, processor and memory capacity) on an approach that usually never works for me?
If the progress bar works in 100 steps, then each step represents 1%. That 1% on 1,500,000 lines means that 1 step corresponds to 15,000 lines. Now we don't know exactly what the length of each 15,000 lines is. However, it is responsible to use a statically based calculation. Given the large number, an assumption of the average length is reasonably feasible. You can then divide this estimated average length by the file length to find an estimated number of lines for the progress bar. You can also take advantage of the user's patience disappearing to make a pessimistic assessment, which will make the final steps much faster for the user.
And yes, if the length of the lines in the file is as variable as the weather, you can still recalculate the average line length when processing the file and use it for the next calculation if necessary.
This flip-thinking solution saves reading the file and therefore time and uses hardly any memory space and, as long as the file length is reasonably large, I expect that the user will not notice much of this estimate approach.