Uv14. 1.1 1002 on windows : expected blink 0x0

Manu,

When this happens, are any actual errors found in the files - and if so what?

Otherwise - has anything changed at the time this started occurring ? - and I am assuming RFS is off - please confirm or whether otherwise. The UniVerse ‘errlog’ or Windows event logs may also have some useful information. 

In the old days I would have suggested incresing MFILES significantly and see what happens, though there should be no reason why this would have an effect for a long time now. I also can’t see any reason why having multiple files pointing at the same indexes - which can happening when using absolute index paths and copying files at the O.S level particularly - could have any relevance, as that hits the index files. 

Off-the-wall question - is there any possibility that UniVerse files are being copied or overwritten while UniVerse is up and running and the database is not suspended?

Regards

JJ

Hi Hohn,
Thank you for your suggestions,  I’ll re-checked all theses usual stuff.
I suspect a non-uv element … running smoothly from years, it appears recently, … something is changed ! but what ?
With kind regards

manu

I found a strange message in uvsmm.log 
 

Starting: (1761289118)Fri Oct 24 08:58:38 2025

Calling from uvsmm, skip U_s_attctl()
too many sb toggles =<13, 261, 7878, 7878>
Calling from uvsmm, skip U_s_attctl()

  UVSMM checking interval...........: 15 seconds
  UVSMM process id..................: 7892

is the -too many sb toggles- a problem ?? 
Thanks for any comment.

Manu,

That’s one for Rocket support - please open a support ticket with them in this one. As a minimum that error and its meaning and significance should be documented - even if only a caution.

In general terms it dounds like a resource limitation on an access control system - please let us know the outcome.

Regards

JJ

Hello

I'll add a fact about  ACL rights. 

On uvhome -PERMISSIONS subr return 555, but on other account level directory it return 777. And I can't make a ED &UFD& item (At FI, I get a write failure). 

And when I compare icacls for the two directories I do not read any differences.? 

Thanks for any sugg. 

Manu 

Manu,

Would be interesting to compare the write behaviour with opening a Windows Console session having ogged in on the console with the same credentials used fro UV to get this error. ‘cd’ to the relevant directory where UV gets a failure and t ry writing a new file with ‘echo “test” > testfile’ (as an example) and also (from there) open a UV shell from DOS in the account and try editing via &UFD& again - checking &UFD& points at the current directory.

Any new software loaded at the Window level that could be hogging ar a possible hostile AV update?

Regards

JJ

Hi John

Thank you to continue the discussion. 

The test you suggest was done and give no trouble. 

I identify this : if I create a file via BASIC OPENSEQ ELSE CREATE the osfile is created but with attribute READONLY !

Then next WRITESEQ crash… ELSE Clause and status() is 0

I do not understand how it's possible, what can turn the readonly attribute =ON while the file is open, lock is set properlly.... 

I found no argument in BASIC to define the OPENSEQ/CREATE mode (r/rw/w) as we have in other language 

Status : searching…

Regards 

Manu,

This feels like a Windows policy setting - likely a GPO - and if it works fro UV from a command prompt but not from UV in Telnet then it could be associated with processes spawned from the Telnet service.

To confirm - does the same BASIC program creation fail from TELNET but work from a  UV shell at the command prompt?

Regards

JJ

Hi, 
to close the discussion, it was a antiVirus too much enforcement ! 
We disable it totally and we ‘ll re-configure from scratch. 
thanks for your help and suggestions.
manu

Manu,

It would be useful to know the AV product concerned for future reference if you are able to share? Feel free to PM me.

Regards

JJ