#280 Linux doesn't seem to honor file locks

[Erich]

On Linux, a file that is open and locked (by not specifiying any SHARExxxx options), when openend a second time, will return "READY:" instead of "ERROR:13 Permission denied" as it does on Windows.

f = "existing.file"
s = .Stream~new(f)~~open("read") -- opens and locks file
say s~description                -- READY:
t = .Stream~new(f)~~open("read") 

say t~description                -- on Linux   READY:
                                 -- on Windows ERROR:13 Permission denied

[LesK]

If it's non-damaging, and it must not be if it can be shared READ, then the Linux
behavior sounds 'right' to me. On the Windows side, is it the driver, ooRexx or the OS
that is doing the Permission Denied?

[Rene Vincent Jansen]

works as designed in linux, move to close

[Bruce]

I agree, but it is sad that this is yet another example of non-portability. A UNIX/LINUX programmer would get the expected result. The Windows programer would get the expected result. Only the programmer trying to write portable software would be left scratching their head. Documentation issue?

[Erich]

| works as designed in linux, move to close

René, can you give us more details, why this difference is to be expected?

[Bruce]

Historically UNIX/LINUX fopen command doesn't provide file locking.

[Erich]

Ticket moved from /p/oorexx/bugs/1397/

Can't be converted:

• _pending_work_items: none

[Erich]

rexxref should be updated