.jou file -- insufficient privilege

[Joseph Dellwo]

I'm unable to edit some files due to .jou files that are protected. It looks like other employees exited the editor by hitting ctrl-z several times and that leaves these .jou files.
This seems pretty common and is getting frustrating. Is there any way around this? I'm not an administrator.

Thanks, Joe

[Dale A. Marcy]

More than likely, the users are hitting either ctrl-c or ctrl-y to exit the editor. This leaves the .jou files. If you exit or quit the editor normally, the file is deleted automatically. To get around the existing .jou files that you do not have access, try editing from a different directory as I believe the .jou gets created in your default location. If the file to be edited is in Disk:[Dir1], then set default to Disk:[Dir2] and edit Disk:[Dir1]File.Ext.

[Jim_McKinney]

Additionally, you could temporarily rename your file to something unique prior to editing and rename it back once done, or, if you're confident that your session won't end prematurely (or don't mind re-doing your edits if it does) you can specify /NOJOURNAL on the command line when invoking EDT.

[Robert Gezelter]

Joe,

The JOU file is created in the current default directory. If you do not have permission to write in that directory, there will be problems creating the journal file.

Do you have write access to that directory? Write access to the directory is not the same as write access to the file.

If needed, you can redirect the JOU file to a different location (e.g., your login directory) or suppress it altogether. Do HELP EDIT /EDT /JOURNAL for details.

- Bob Gezelter, http://www.rlgsc.com

[RBrown_1]

One way to get around this problem is to use EVE instead of EDT. I find EVE with the EDT keypad (DEFINE EVE$KEYPAD EDT) to be my preferred replacement for EDT. I think EVE protects its journal file differently so you don't run into this problem even if you do have users leaving obsolete journal files lying around.

How bad is the problem? Are new .JOU files left lying around daily? Weekly? Find the bad guys who are creating them and make them delete them.

Work for your system manager:

1. Delete all of the .JOU files.

2. Consider granting an identifier to all who are authorized to edit these files. Create an ACL granting (ACCESS=READ+WRITE+EXECUTE+DELETE) to holders of this identifier. Apply this ACL to all affected files and directories.

[Joseph Dellwo]

That almost worked. I was able to get around the file.jou protection and edit. But when I tried to save, it gave me a file.tmp protection error. That file is in the original directory with the file.jou.

I also did edit/nojournal (same result) but I'm wondering is there a /notemp or something?

Thanks, Joe

[Joseph Dellwo]

Wow, I was replying to the 1st messages and there a bunch more before I finished.
I had one guy delete his .jou's and showed him how to do it correctly. The other guy is on another shift (for the ones I'm trying now). I guess I'll have to wait unless there's another idea. I'll try some more of you suggestions shortly.

Thanks alot, Joe

[Hoff]

Look up "resource identifier" in the guide to system security manual in the OpenVMS documentation set for an approach to this end, and aim these journal files at the location with whatever the editor might be here, or by aiming SYS$SCRATCH: at the shared directory area you've established. That's a potential fix for this. The resource identifier ends up owning the files, which means anyone with the identifier can manage (read, write, delete) the files.

It is also clear that there are some significant issues here with the system security configuration, and quite possibly some security exposures. I'd get the security reviewed, lest you either expose sensitive information (such as via the journal files in the shared area, as described above) or lest somebody cross between the users and UICs identified here that are sharing directories.

There is a reasonable chance that parallel edits might be (or are?) getting lost. Colliding journal files can mean colliding filenames. Which means this sequence could mean that edits are lost. That turns into a discussion of code management systems and/or of local (usually DCL) hacks that lock out parallel accesses to shared files.

Stephen Hoffman
HoffmanLabs LLC

[Joseph Dellwo]

Ok...to recap.
I can get around the file.jou issue with eve or edt/nojournal. But some of the files also have an associated file.tmp that won't allow me to save my changes due to insufficient privileges. Some files just have the file.jou and I can save fine.

Any ideas to get around the file.tmp?
I'll send him an e'mail to delete them but I'd like to update these scripts while I have the momentum. They are all several years old...probably when he first started.

[Hoff]

You'll need to assign a resource identifier or a default identifier on the area you're writing these temporary files, or a default protection. These are described in the security manual, and in various ACL-related OpenVMS presentations.

In any event, these allow-access approaches can also open up cross-user access and can thus be considered insecure; folks can potentially read each others' files.

The whole area of these environment appears broken.

You could also set up a per-user SYS$SCRATCH area.