Rocket U2 | UniVerse & UniData

 View Only

 Write/Delete Fail to Linux Dir

John Israel's profile image
John Israel posted 05-09-2024 10:28

I have a program that does a bunch of initial stuff, but at the end, writes a JSON (text) file to a UniData DIR file called JSON.ARCHIVE with a date-time stamp.  It then does a chmod on the new file, setting permissions to 666.  Finally, it selects all the records  (files) in JSON.ARCHIVE that are older than 35 days and deletes them, thus it is self-cleaning.

For some reason, the writes and deletes have stopped working.  I do not get an error, and the delete counter increments, but when I LIST JSON.ARCHIVE, my new record is not there and the old ones were not deleted.

Permissions on the Linux dir are drwxrwxrwx, and all the files within are -rw-rw-rw-.

For argument's sake, we have three accounts: DEV, PILOT and LIVE.  The programs are all the same and had not been compiled since I rolled the programs out.  It still works in DEV but no longer in PILOT or LIVE.  To be sure, I re-compiled DEV - it still worked.  I copied the working program from DEV to PILOT, re-compiled in PILOT, and PILOT still does NOT work.

From TCL, I am able to edit a new record, save it and delete it.

I am running out of ideas...

Jonathan Smith's profile image
ROCKETEER Jonathan Smith posted 05-09-2024 10:47

Hi @John Israel

A few things

  1. Is the version of UniData running on 3 machines the same, if not what are the different versions.
  2. Is the version of Linux the same on all 3 machines and what flavour of Linux are you using
  3. Looking at the Linux permissions it does not appear that ACL permissions would be in play as no '+' symbol is being displayed in your description, just make sure that someone hasn't turned on ACL permissions

How is the basic program creating the records, WRITESEQ or WRITE etc. Maybe a few snippets from the code where the records are being written and manipulated might help.

John Israel's profile image
John Israel posted 05-10-2024 08:20

This is all running on a single Linux box, so the UniData and OS are the same.  Here is more info I found:

  • I deleted all the txt files from JSON.ARCHIVE.
  • I ran the program that writes and deletes (old) txt files - no problem.  I ran it again - no problem.
  • I added a dummy record with the editor.
  • I ran the program that writes and deletes txt files - it no longer writes anything!!!
  • I delete the dummy record with the editor.
  • I ran the program that writes and deletes txt files - now it works!

WHAT???

The same thing happens if I use CNAME to change the ID of an existing txt file.

It was me doing all of this, so all the txt files had me as the owner and the normal permissions.

It is as if: if anything other than the write/delete program updates anything in the file/dir, the program no longer works (but gives no errors that it didn't).

Attachments  View in library
WRITE.png 17 KB
DELETE.png 37 KB
John Jenkins's profile image
John Jenkins posted 05-12-2024 11:21

I'd defiinitely check the ACLs - these can be user and group specific for a directory / directory tree or an individual file. Steps to check:

  • Use getfacl to get any ACLs and check then from root down.
  • Check directory ownership for user and group and run chmod g+s on the directory
  • Try pointing at a directory where it does work from mthe accouint where ir doesn't - and vice versa. Is the iussye the user or the directory?
  • Use truss -f -p PID 1>truss_PID.out 2>truss_PID_err.out from another session running as root on the PID of the databases ession on which you will be using the program. Run and fail - check the truss files for a failure and potential cause.

Regards

JJ

John Israel's profile image
John Israel posted 05-13-2024 08:20

AGH!  Found the problem - self inflicted.  A minor typo in my program that was not throwing an error.  It was writing the new file, then immediately deleting it (and not deleting the old files).

Rookie mistake.