Write does not work on DOSBox-X

[ApprenticeofEnder]

It looks like the actual file write function does not work with what I've tested. It looks like the write function makes no actual modifications to the file. I'm not entirely sure I'm doing anything wrong. I noticed the file tests notably lacked any write tests, though, so this might be relatively recent functionality.

I wonder if there's a call missing somewhere, maybe to actually flush the buffer? Assembly is pretty far from my domain of expertise, sadly.

I tried this on DOSBox-X on Windows (version 2023.10.06 specifically, if that makes a difference). I tried a bunch of different things:

• Using the same file object for read, seek, and write (nope)
• Using the same file object but opening and closing it between operations (nope)
• Using two different file objects operating on the same file (nope)
• Using two different file objects, one for a source file and one for a destination (nope, this actually caused a panic if the second file didn't exist so no programmatic creation here)

With the last test, I created a completely blank file in DOSBox, which after the modifications should have been 13000 bytes in size, yet remained at size 0 after the program finished running.

For reference, here's the relevant part of main.rs (this is for TryHackMe's Advent of Cyber 2023):

use day5_payload::{*, dos::file::File};

entry!(main);

fn main() {
    let filename_src: &str = "TEST.TXT";
    let filename_out: &str = "TEST_2.TXT";

    let fix_bytes: [u8; 2] = [0x41, 0x43];

    println!("Opening: {}", filename_src);
    let src_file: File = File::open(filename_src).expect("Check file name and try again?");

    println!("Reading...");
    let mut buf = [0; 13000]; //Target file is a little over 12,700 bytes
    let bytes_read = src_file.read(&mut buf).unwrap();
    println!("Read {} bytes", bytes_read);

    src_file.close().unwrap();
    println!("Closed source file.");

    println!("Opening for write: {}", filename_out);
    let out_file: File = File::open(filename_out).expect("Error opening outfile.");

    fix_bytes.iter().enumerate().for_each(|(index, byte)| {
        buf[index] = *byte;
    });

    println!("First two bytes of buffer: {} {}", buf[0], buf[1]);
    println!(
        "First two bytes of patch buffer: {} {}",
        fix_bytes[0], fix_bytes[1]
    );
    assert_eq!((buf[0], buf[1]), (fix_bytes[0], fix_bytes[1]));

    let bytes_written = out_file.write(&buf).unwrap();
    println!("Wrote {} bytes", bytes_written);

    out_file.close().unwrap();
    println!("Modification complete. Please confirm modifications manually.");
}

[RandomInsano]

I think I had some problems here myself. I forked awhile ago and made some changes: 80986b6 <80986b6> If I recall correctly, the problems are with the segment registers pointing to the wrong memory. It's been nearly a year though since I poked around in there. 😃

…

On Dec 22, 2023, at 1:51 PM, Robert Babaev ***@***.***> wrote: It looks like the actual file write function does not work with what I've tested. It looks like the write function makes no actual modifications to the file. I'm not entirely sure I'm doing anything wrong. I noticed the file tests notably lacked any write tests, though, so this might be relatively recent functionality. I wonder if there's a call missing somewhere, maybe to actually flush the buffer? Assembly is pretty far from my domain of expertise, sadly. I tried this on DOSBox-X on Windows (version 2023.10.06 specifically, if that makes a difference). I tried a bunch of different things: Using the same file object for read, seek, and write (nope) Using the same file object but opening and closing it between operations (nope) Using two different file objects operating on the same file (nope) Using two different file objects, one for a source file and one for a destination (nope, this actually caused a panic if the second file didn't exist so no programmatic creation here) With the last test, I created a completely blank file in DOSBox, which after the modifications should have been 13000 bytes in size, yet remained at size 0 after the program finished running. For reference, here's the relevant part of main.rs (this is for TryHackMe's Advent of Cyber 2023): use day5_payload::{*, dos::file::File}; entry!(main); fn main() { let filename_src: &str = "TEST.TXT"; let filename_out: &str = "TEST_2.TXT"; let fix_bytes: [u8; 2] = [0x41, 0x43]; println!("Opening: {}", filename_src); let src_file: File = File::open(filename_src).expect("Check file name and try again?"); println!("Reading..."); let mut buf = [0; 13000]; //Target file is a little over 12,700 bytes let bytes_read = src_file.read(&mut buf).unwrap(); println!("Read {} bytes", bytes_read); src_file.close().unwrap(); println!("Closed source file."); println!("Opening for write: {}", filename_out); let out_file: File = File::open(filename_out).expect("Error opening outfile."); fix_bytes.iter().enumerate().for_each(|(index, byte)| { buf[index] = *byte; }); println!("First two bytes of buffer: {} {}", buf[0], buf[1]); println!( "First two bytes of patch buffer: {} {}", fix_bytes[0], fix_bytes[1] ); assert_eq!((buf[0], buf[1]), (fix_bytes[0], fix_bytes[1])); let bytes_written = out_file.write(&buf).unwrap(); println!("Wrote {} bytes", bytes_written); out_file.close().unwrap(); println!("Modification complete. Please confirm modifications manually."); } — Reply to this email directly, view it on GitHub <#22>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAARO2TOAEBCOLSNLWEP2RTYKXQFJAVCNFSM6AAAAABBAGPVJ2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGA2TINBVGU3TGOA>. You are receiving this because you are subscribed to this thread.

[RandomInsano]

Sorry, this is a better commit: 984d246 <984d246>

…

On Dec 22, 2023, at 2:05 PM, Edwin Amsler ***@***.***> wrote: I think I had some problems here myself. I forked awhile ago and made some changes: 80986b6 <80986b6> If I recall correctly, the problems are with the segment registers pointing to the wrong memory. It's been nearly a year though since I poked around in there. 😃 > On Dec 22, 2023, at 1:51 PM, Robert Babaev ***@***.*** ***@***.***>> wrote: > > > It looks like the actual file write function does not work with what I've tested. It looks like the write function makes no actual modifications to the file. I'm not entirely sure I'm doing anything wrong. I noticed the file tests notably lacked any write tests, though, so this might be relatively recent functionality. > > I wonder if there's a call missing somewhere, maybe to actually flush the buffer? Assembly is pretty far from my domain of expertise, sadly. > > I tried this on DOSBox-X on Windows (version 2023.10.06 specifically, if that makes a difference). I tried a bunch of different things: > > Using the same file object for read, seek, and write (nope) > Using the same file object but opening and closing it between operations (nope) > Using two different file objects operating on the same file (nope) > Using two different file objects, one for a source file and one for a destination (nope, this actually caused a panic if the second file didn't exist so no programmatic creation here) > With the last test, I created a completely blank file in DOSBox, which after the modifications should have been 13000 bytes in size, yet remained at size 0 after the program finished running. > > For reference, here's the relevant part of main.rs <http://main.rs/> (this is for TryHackMe's Advent of Cyber 2023): > > use day5_payload::{*, dos::file::File}; > > entry!(main); > > fn main() { > let filename_src: &str = "TEST.TXT"; > let filename_out: &str = "TEST_2.TXT"; > > let fix_bytes: [u8; 2] = [0x41, 0x43]; > > println!("Opening: {}", filename_src); > let src_file: File = File::open(filename_src).expect("Check file name and try again?"); > > println!("Reading..."); > let mut buf = [0; 13000]; //Target file is a little over 12,700 bytes > let bytes_read = src_file.read(&mut buf).unwrap(); > println!("Read {} bytes", bytes_read); > > src_file.close().unwrap(); > println!("Closed source file."); > > println!("Opening for write: {}", filename_out); > let out_file: File = File::open(filename_out).expect("Error opening outfile."); > > fix_bytes.iter().enumerate().for_each(|(index, byte)| { > buf[index] = *byte; > }); > > println!("First two bytes of buffer: {} {}", buf[0], buf[1]); > println!( > "First two bytes of patch buffer: {} {}", > fix_bytes[0], fix_bytes[1] > ); > assert_eq!((buf[0], buf[1]), (fix_bytes[0], fix_bytes[1])); > > let bytes_written = out_file.write(&buf).unwrap(); > println!("Wrote {} bytes", bytes_written); > > out_file.close().unwrap(); > println!("Modification complete. Please confirm modifications manually."); > } > — > Reply to this email directly, view it on GitHub <#22>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAARO2TOAEBCOLSNLWEP2RTYKXQFJAVCNFSM6AAAAABBAGPVJ2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGA2TINBVGU3TGOA>. > You are receiving this because you are subscribed to this thread. >

[ApprenticeofEnder]

I'll give this a shot, thanks!

[RandomInsano]

Sounds good! If you want to open PRs against my fork, I also do my testing in DOSBox and happy to merge it in. Note, the memory allocation in both repos fails on real hardware because it allocates across segmentation boundaries and it drove me crazy enough that I dropped my project. I got to learn what “segmentation fault” really meant 😆 On Dec 22, 2023, at 3:23 PM, Robert Babaev ***@***.***> wrote: I'll give this a shot, thanks! —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>