Description: In a BASIC macro, OPEN path FOR BINARY AS #fnum does not delete any existing file and create a fresh file. Pitonyak's guide to LibreOffice Macros indicates that the behavior with respect to deleting an existing file and creating a new file should be identical to that of OPEN path FOR OUTPUT AS #fnum I find that OPEN FOR OUTPUT *does* delete any existing file. (Or at least, it truncates the existing file to zero length.) When the file exists, and is larger than what I am writing after OPEN FOR BINARY, the resultant file is what I wrote in BINARY, followed by what's left of the original file; i.e., it appears that the beginning of the file was overwritten, but the CLOSE did not leave the end of the data in the file as the last thing I just wrote. Steps to Reproduce: 1. Copy a file to "x.txt" 2. Write a macro in LibreOffice that opens "x.txt" FOR BINARY, writes a few bytes, and closes. 3. Run the macro 4. Check the file to see if there is anything past the few bytes written by the macro. Actual Results: newoldoldold Expected Results: new Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: en-US Module: StartModule [Information guessed from browser] OS: Windows (All) OS is 64bit: yes Version: 5.4.3.2 (x64) Build ID: 92a7159f7e4af62137622921e809f8546db437e5 CPU threads: 4; OS: Windows 6.19; UI render: default; Locale: en-US (en_US); Calc: group
(In reply to Jay Michael from comment #0) > 2. Write a macro in LibreOffice that opens "x.txt" FOR BINARY, writes a few > bytes, and closes. Please write the macro here. Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the information.
https://opengrok.libreoffice.org/xref/core/basic/source/runtime/iosys.cxx?r=7af90cc9#444
(In reply to Buovjaga from comment #1) 2. Write a macro in LibreOffice that opens "x.txt" FOR BINARY, writes a few bytes, and closes. sub wb( fn as integer, byteval as integer ) dim v as byte v = byteval put #fn,, v end sub Sub Main const fname = "c:\users\jay\x.txt" dim fn as integer fn = freefile() open fname for binary as #fn wb(fn,asc("n")) wb(fn,asc("e")) wb(fn,asc("w")) wb(fn,13) wb(fn,10) close fn End Sub Change "fname" to point to your own home directory. Do not have "x.txt" open in LibreOffice while running the macro "Main".
(In reply to himajin100000 from comment #2) > https://opengrok.libreoffice.org/xref/core/basic/source/runtime/iosys. > cxx?r=7af90cc9#444 Was this meant for me? I can believe that the line you indicate shows that if the mode is binary, the file will not be deleted. That's certainly consistent with what I observed.
Thanks. Step 1 should include that the text file must not be empty, so you see what changes. Version: 6.2.0.0.alpha0+ (x64) Build ID: 414ef6cb187dd3bbcc917dbedf3c0c1cc8668f60 CPU threads: 4; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-08-21_00:13:04 Locale: fi-FI (fi_FI); Calc: threaded Arch Linux 64-bit Version: 6.2.0.0.alpha0+ Build ID: 1c59d021b3dd27c8c0255312bd0d53ad25965bab CPU threads: 8; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5; Locale: fi-FI (fi_FI.UTF-8); Calc: threaded Built on September 1st 2018
(In reply to Buovjaga from comment #5) Is there a way for me to edit my original post? Should I make a new comment/reply that includes the original post, and includes the changes you've indicated?
(In reply to Jay Michael from comment #6) > (In reply to Buovjaga from comment #5) > > Is there a way for me to edit my original post? > > Should I make a new comment/reply that includes the original post, and > includes the changes you've indicated? It's fine. The next version of Bugzilla will hopefully have editing functionality.
I am really unsure that this is a bug. The Binary mode is not equivalent to "For Output". The actually relevant documentation is that of Put [1] [2]; note that Binary files are treated ~same as "Random", and that implies that the files are not truncated, but just read and written randomly, with "record" being a single byte. And for the record, current behavior of LibreOffice Basic is perfectly consistent with what VBA does (tested using Excel 2016). [1] https://help.libreoffice.org/latest/en-US/text/sbasic/shared/03020204.html [2] https://docs.microsoft.com/en-us/office/vba/Language/Reference/User-Interface-Help/put-statement
Reading Andrew Pitonyak's OOME3.0 [1] ch.8.6 "Open a file", I see it is clearly misguided. It tells that both "For Binary" and "For Random" "delete" existing files when Access is not used; also it states that "Access Read Write" would "[D]elete an existing file". These statements are incorrect, and should not be a rationale to change the correct implementation into incorrect. [1] https://www.pitonyak.org/OOME_3_0.pdf
I just read Andrew Pitonyak's documentation, where it states that it behaves the same, but you are right: Basic is perfectly consistent with the current behaviour. Imho we can close this bug.
FTR: Keeping files open For Binary was implemented in 2004 (see https://git.libreoffice.org/core/+/23b49669ab70cac72d5f6d955e7d2af617e6934e) for i#18638 (so it appeared in OOo 2.0). Keeping files open For Random was implemented in 2015 (git.libreoffice.org/core/+/42a63dd0e81f13a84a5f551e03ede685e2bf34c7) for i#61277 (likely will appear in AOO 4.2). Somewhere in the LO 3.5 development cycle, we made files opened For Binary not append, but correctly rewrite from start. I have not identified the commit.