Fwd: [GnuCOBOL 3.2] testsuite: 905 failed

[Simon Sobisch]

Hi John and welcome to GnuCOBOL!

Thank you for taking the time to send the mail - especially as we don't 
have a report for that (until told otherwise I think you've checked that 
at https://lists.gnu.org/archive/html/bug-gnucobol/ :-)

Am 09.08.2024 um 18:22 schrieb John Imrie:
> Log file and config.h attached.
>
> This is running Ubuntu Linix under Windows subsystem for linux


Here is the relevant part of testsuite.log (which also includes 
config.h, btw):


## ---------------------- ##
## Detailed failed tests. ##
## ---------------------- ##

#                             -*- compilation -*-
905. run_file.at:5775: testing SEQUENTIAL file with SHARING READ ONLY ...
./run_file.at:5842: $COMPILE prog1.cob
./run_file.at:5843: $COMPILE prog2.cob
./run_file.at:5844: $COBCRUN_DIRECT ./prog1
--- /dev/null   2024-08-09 16:36:18.263781700 +0100
+++ 
/mnt/c/Users/John/Downloads/gnucobol-3.2_win/tests/testsuite.dir/at-groups/905/stdout 
2024-08-09 16:55:54.947255200 +0100
@@ -0,0 +1 @@
+FAILED 1: 00
905. run_file.at:5775: 905. SEQUENTIAL file with SHARING READ ONLY 
(run_file.at:5775): FAILED (run_file.at:5844)


This does show that the locking for read-only is not working in WSL when 
you operate on Windows disks /mnt/ (the lock operation gets back as "all 
fine", so libcob can't do anything about that, but it does not work).

If you consider this locking important, then use GnuCOBOL in WSL under 
WSL directories (will be also a big speed boost as well) like under /tmp 
or /home/$USER/myapp.

As no other tests failed, locking with exclusive access _may_ work on 
Windows mounted disks (verify when important) - which then could provide 
you with a workaround on the COBOL application side.

Note: you will also find that this and other kinds of locking don't work 
correctly on network shares - if locking is important then always checks 
the locking capabilities of the underlying storage.

Simon