A call to BufReader<File>::lines().count() on a non-read opened file in Linux never returns.

[joelself]

Not much to it. I have this bit of code:

fn get_line_count(file_name: String) -> Result<usize, Error> {
    let file = try!(OpenOptions::new().append(true).create(true).open(&file_name));
    let f = BufReader::new(file);
    Ok(f.lines().count())
}

And I'm passing in a file that exists, but is empty (actually, by the timestamp, the file probably didn't exist until the first line in the function created it):

ls -la new_chunks.txt 
-rw-rw-r-- 1 joel joel 0 Jul  7 07:38 new_chunks.txt

My program wasn't going anywhere, but it was using up 100% of one core. Some printlns later and I found that it couldn't get past Ok(f.lines().count()). Specifically it was the call to count() that wasn't returning.

This is Ubuntu 14.04. rustup show:

active toolchain
----------------

stable-x86_64-unknown-linux-gnu (default)
rustc 1.9.0 (e4e8b6668 2016-05-18)

Edit: This was running in release mode, but I confirmed it in debug mode too. I also tried the current beta and nightly channels in release and debug mode:

beta-x86_64-unknown-linux-gnu (directory override for '/home/joel/dirname/dirname/project')
rustc 1.11.0-beta.1 (8dc253bcf 2016-07-05)

nightly-x86_64-unknown-linux-gnu (directory override for '/home/joel/dirname/dirname/project')
rustc 1.11.0-nightly (696b703b5 2016-07-03)

[joelself]

In case anybody else encounters this and needs a workaround, here's what I've been doing before I discovered the Lines Iterator and it seems to work fine on even really sketchy files that have encoding that varies within the file (including lines with invalid encoding):

    let mut f = BufReader::new(file);
    let mut count = 0;
    let mut line = String::new();
    if let Ok(mut bytes) = f.read_line(&mut line) {
        while bytes > 0 {
            // Do something with the line
            count += 1;
            line.clear();
            match f.read_line(&mut line) {
                Ok(b) => bytes = b,
                Err(_) => {},
            }
        }
    }

Edit: Alternatively, if you want to open a file for read you could, you know, just open the file for read I guess. If you're into that sort of thing.

[alexcrichton]

This appears to be a few things at play:

• The file descriptor is not opened for reading, so attempts to read it (at least on linux) are returning EBADF
• This causes the iterator to continuously yield Some(Err(..)) values
• The implementation of count exhausts an iterator (calls next until None) so it never returns

The "fix" here would be to fuse the lines iterator once an error is returned once and force it to return None afterwards, but that's also unfortunately not a great fix.

[joelself]

Ah, this the first time I tried OpenOptions and I just copied from another spot in my code that doesn't need read(true).

[Dylan-DPC]

Closing this as this error was formed due to a misuse of the API

[hkBst]

Coming here from #64144. The example code here is old, but I've updated it and it still behaves the same. Eyeballing the code it seems harmless, so it is unfortunate that it is an infinite loop.

use std::path::Path;
use std::io::{BufReader, BufRead};
use std::fs::OpenOptions;

fn get_line_count(file_name: impl AsRef<Path>) -> Result<usize, std::io::Error> {
    let file = OpenOptions::new().append(true).create(true).open(&file_name)?;
    let f = BufReader::new(file);
    Ok(f.lines().count())
}

#[test]
fn t() {
    assert_eq!(get_line_count("test").unwrap(), 0);
}