Set file permission fortran - file

I get this error:
forrtl: severe (9): permission to access file denied, unit 900, file C:\Abaqus_JOBS\mEFT.txt
When I try to open and simultaneously create the file C:\Abaqus_JOBS\mEFT.txt:
OPEN(900, FILE = "C:/Abaqus_JOBS/mEFT.txt", action = "READWRITE", status = "UNKNOWN")
The error occurs and the file is not created. When the error occurs the file has already been created and deleted at least 100 times.
EDIT:
It seems the error is related to the fact that Windows don't delete or close the files immediately and in a parallel computation one could try to access the file when the file still exists... any ideas how to solve this issue?

Related

(Lua 5.2) Cannot create file because io.open returns nil file handle

I am trying to create a file in Lua.
The following threads all say the same thing:
https://forum.rainmeter.net/viewtopic.php?t=10024
Create a new file in Lua/LuaFileSystem
Sifteo: how to create a file.txt with LUA script?
Creating new files with Lua I/O functions
They say to use:
local file = io.open("test.txt", "w")
file:write("Hello World")
file:close()
I have implemented this like so:
local ADDRESSES = "capi/addresses.cfg"
local file, err = io.open(ADDRESSES, "w")
local data = "<DATA>"
file:write(data)
file:close()
This, however, results in the error Attempt to index local 'file' (a nil value). This is, of course, because the file does not exist because I am trying to create it. The examples seem to say that the file should be automatically created when I try to write to it, but how can I do that if the handle is nil!?
It is correct that io.open(filename, "w") will create the file if it doesn't already exist.
However, there are at least three prerequisites common to file operations:
You must have sufficient permissions to create the file in the desired path (e.g. write permission in the folder)
All folders along the path must already exist. Lua will not create folders for you.
There must be sufficient space (your file system may not be full)
You are presumably not meeting one of the prerequisites. To find out which, simply wrap your call to io.open with assert:
local file = assert(io.open(ADDRESSES, "w"))
Now if opening/creating the file fails, Lua will throw an error that tells you which prerequisite you failed to meet.
In your case, I would consider it most probable that the capi directory doesn't exist yet. On my Linux system, the corresponding error message is capi/addresses.cfg: No such file or directory.

GStreamer hlssink2 fails with "Failed to delete fragment file"

hlssink2 gives this error out of nowhere after a few seconds of streaming:
Error received from element hlssink: Failed to delete fragment file '/tmp/gnome-networks-display/nd-segment000007.ts': Error removing file /tmp/gnome-networks-display/nd-segment000007.ts: No such file or directory.
Debugging information: ../ext/hls/gsthlssink2.c(479): gst_hls_sink2_handle_message (): /GstPipeline:nd-cc-pipeline/GstHlsSink2:hlssink
Where does it store the last stream info? Even after cleaning the directory, it starts off the segments from the number left off in the last stream (eg. from nd-segment000046.ts).
Some help here would be greatly appreciated.

AS 400- Sequential File not getting written. No error in the status. COBOL 400

I'm declaring a sequential file :
SELECT F-MYFILE ASSIGN DATABASE-MYFILE
ORGANIZATION SEQUENTIAL
ACCESS SEQUENTIAL
STATUS WW-STS-MYFILE.
In my COBOL program I am opening it as:
OPEN extend F-MYFILE
IF WW-STS-MYFILE NOT="00"
GO TO FINISH
END-IF
INITIALIZE MYFILE
MOVE "abcd" TO CONTENT OF MYFILE
WRITE MYFILE.
While I am writing the record the file is not showing any error in the status WW-STS-MYFILE, its '00'.
But still the record is not getting written.
Could you please tell the possible reason for the same.
Thanks
I'm not that familiar with AS/400 as I'm a z/OS developer, but the rule of thumb I've followed is that you read a file, but you write a record. if MYFILE is the filename and not a record layout for that file, then you are trying to write a file instead of a record for that file.
Does your program CLOSE the file? Is the file under commitment control? If you're using commitment control, and you haven't done a COMMIT or a CLOSE, the record(s) will be rolled back automatically when the program ends.
If you try to view the file while the program is still running, before it CLOSEs the file, it may be a file buffering issue.

working with files on "start without debugging"

I'm programming in C, and
I have the following problem:
I use fopen and try to read from a csv file, that is currently storred in the folder of the exe file of the program.
the program works fine in debug mode and release mode, but when I try to run the program in "start without debugging" on visual studio 2008 express edition, the program stops working and windows is showing a message: "*.exe has stopped working. a program caused the program to stop working correctly. windows will close the program and notify you if a solution is available".
I've tried running the program on several computers, and it's the same.
another information I can give you is that if I enter the full path of the file (C:....file.csv) - then is works just fine, without any problem.
I know I didn't write any code, but I hope someone will have an idea why this can happend.
thanks is advance.
Your program is not finding the csv file, fopen() fails and return a null pointer, you try to use it without checking and your program crashes (just my guess).
Firstly, you must make a check to see if fopen() could indeed open your file:
FILE* f = fopen("file.csv", "r");
if(f == NULL) {
/* print some meaningful error */
} else {
/* use the file */
}
Secondly, you may solve the problem by executing your program from the same folder the file is present. I am not a Windows guy, but if you create a link to the ".exe", in its properties may have some configuration called "Working Directory" or something like that, that you may set to the path on where the file can be found.
Every process has a working directory, that is usually the directory from where it was started, though it may be inherited from the parent process and it may be changed programmatically. If you do not specify the full path when loading a file, the process will search for the file in its current working directory.

Check if file is locked or catch error for trying to open

I'm trying to handle the problem where a user can try to open, with an OpenFileDialog, a file that is open by Excel.
Using the simple FileInfo.OpenRead(), it chucks an IOException, "The process cannot access the file 'cakes.xls' because it is being used by another process." This would be fine to display to the user except that the user will actually get "Debugging resource strings are unavailable" nonsense.
It seems not possible to open a file that is open by another process, since using FileInfo.Open(FileMode.Open, FileAccess.Read, FileShare.ReadWrite) chucks a SecurityException, "File operation not permitted. Access to path 'C:\whatever\cakes.xls' is denied.", for any file. Rather unhelpful.
So it's down to either finding some way of checking if the file is locked, or trying to catch the IOException. I don't want to catch all IOExceptions and assume they're all locked file errors, so I need some sort of way of classifying this type of exception as this error... but the "Debugging resource strings" nonsense along with the fact that that message itself is probably localized makes it tricky. I'm partial trust, so I can't use Marshal.GetHRForException.
So: Is there any sensible way of either check if a file is locked, or at least determining if this problem occurred without just catching all IOExceptions?
I just worked this out: it's as simple as reading the documentation.
FileInfo.Open specifies:
FileNotFoundException - The file is not found.
UnauthorizedAccessException - The file is read-only or is a
directory.
DirectoryNotFoundException - The specified path is
invalid, such as being on an unmapped drive.
IOException - The file is already open.
Thus it's safe to catch all IOExceptions and treat them as this file-is-already-open problem because it's specified that that is the only case an IOException will get thrown.

Resources