Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Writing to a file doesn't update the in memory representation of the file #19

Open
Tracked by #14
MabezDev opened this issue Feb 18, 2024 · 2 comments
Open
Tracked by #14
Labels
bug Something isn't working

Comments

@MabezDev
Copy link
Owner

Consider this snippet:

{
        let mut f = fs.root_dir().create_file("test.log").await.unwrap();
        let hello = b"Hello world!";
        f.write_all(hello).await.unwrap();
        f.flush().await.unwrap();

        let mut buf = [0u8; 12];
        f.read_exact(&mut buf[..]).await.unwrap();
        log::info!("Read from file: {}", core::str::from_utf8(&buf[..]).unwrap());
    }

read_exact currently returns UnexpectedEoF, but if you inspect the disk the size has been updated. To read a file you have just written to you have to re open it.

@MabezDev MabezDev added the bug Something isn't working label Feb 18, 2024
@MabezDev
Copy link
Owner Author

MabezDev commented Feb 23, 2024

Hmm, this appears to be more related to the block device adapters, when write_all is finished, the pointer in the file is at the end, so read begins from the end and fails. This is not the case for std impls. It's not clear how successive reads/writes are meant to happen without moving the seeked position... Need to investigate. Not true, turns out the write test weren't running 😅.

@MabezDev MabezDev mentioned this issue Mar 30, 2024
11 tasks
@aurelj
Copy link
Contributor

aurelj commented Sep 13, 2024

What you show is exactly the expected behavior I think.
On every filesystem I've ever tried, there is only one current position for both read and write, and only one seek() function to change the current position. Any read or write operation always move the current position to the end of the data that was read or written.

So after the write_all(), the current position is at the end of the file, and the next read_exact() has nothing to read.

If you add a

f.seek(SeekFrom::Start(0)).await.unwrap();

between the read and write, your example works as intended.

So I don't think there is any actual issue here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants