Hi Scott,
Yes I certainly did try that option. It did not at all act like ALCOBJ does to truly protect the file from another process getting to it. I was writing a licensing system so it was rather crucial that we be able to create objects that could not be 'messed with' in any way shape or form by another process.
Thanks,
Genyphyr Novak
----- Original Message ----
From: "c400-l-request@xxxxxxxxxxxx" <c400-l-request@xxxxxxxxxxxx>
To: c400-l@xxxxxxxxxxxx
Sent: Tuesday, February 3, 2009 7:00:02 PM
Subject: C400-L Digest, Vol 7, Issue 4
Send C400-L mailing list submissions to
c400-l@xxxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.midrange.com/mailman/listinfo/c400-l
or, via email, send a message with subject or body 'help' to
c400-l-request@xxxxxxxxxxxx
You can reach the person managing the list at
c400-l-owner@xxxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of C400-L digest..."
Today's Topics:
1. Re: C/C++ File Locking (Genyphyr Novak)
2. Re: C/C++ File Locking (Scott Klement)
----------------------------------------------------------------------
message: 1
date: Mon, 2 Feb 2009 14:56:46 -0800 (PST)
from: Genyphyr Novak <genyphyr1@xxxxxxxxx>
subject: Re: [C400-L] C/C++ File Locking
Hi,
As far as the IFS use goes, I opened a call log with IBM support on this at end of last year. I could not find a way to exclusively lock an IFS file to prevent OTHER processes from accessing it or destroying it. I believe if everyone is 'playing nice' and all using the same way to access the file and checking results of open() it is different - but if you want it locked exclusively because you are not sure how someone else might access it, that seems to not work. I was creating a file and tried to open it with some locking in the open( ) ... I tested this ... but I could even delete it from another job while mine first one was 'locking' it and I wanted to prevent exactly this sort of thing from happening. The support center was unable to give me an API or function call to truly lock it from other processes in the same way that ALCOBJ protects 'normal' native iSeries non-IFS objects. I ended up changing to use non-IFS objects on the system. I guess it
depends on the purpose of your code.
Thanks,
Genyphyr Novak
On Mon, Feb 2, 2009 at 11:32 AM, Elvis Budimlic
<ebudimlic@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
If IFS stream file, check out open() function's O_SHARE_NONE flag.
If native (library) file system, check out ALCOBJ command.
Hth, Elvis
Celebrating 11-Years of SQL Performance Excellence on IBM i, i5/OS and
OS/400
www.centerfieldtechnology.com
-----Original Message-----
Subject: [C400-L] C/C++ File Locking
I am new to the iSeries but not C/C++. I am porting a program that runs
on multiple platforms. This program may have several instances running
concurrently but each program shares on data file. My issue is what
function do I use to lock the file so that other apps can not read/write
this file while it is being locked by another process. On windows I
used CreateFile() and on UNIX I used Flock(). I am looking for
something similar or that will at least produce the same results. I
have attempted modifying the share permissions in the CL but this locks
the file for the entire run of the program and not only when this file
is open.
Thanks,
Edgar Gillock
ed_gillock@xxxxxx
------------------------------
message: 2
date: Mon, 02 Feb 2009 17:25:51 -0600
from: Scott Klement <c400-l@xxxxxxxxxxxxxxxx>
subject: Re: [C400-L] C/C++ File Locking
Hello,
As far as the IFS use goes, I opened a call log with IBM support on
this at end of last year. I could not find a way to exclusively lock
an IFS file to prevent OTHER processes from accessing it or
destroying it.
That's what O_SHARE_NONE does. Have you tried it? It works for me...
I believe if everyone is 'playing nice' and all using the same way to
access the file and checking results of open() it is different - but
if you want it locked exclusively because you are not sure how
someone else might access it, that seems to not work.
Assuming that you're using a file system that supports it, O_SHARE_NONE
does exactly that. No other process can open() the file when you have
it opened with O_SHARE_NONE. Anyone trying to open it will fail, and
errno will be EBUSY
creating a file and tried to open it with some locking in the open( )
... I tested this ... but I could even delete it from another job
while mine first one was 'locking' it and I wanted to prevent exactly
this sort of thing from happening.
O_SHARE_NONE only blocks others from opening the file. I don't think it
blocks others from unlinking it. I don't know why this matters, though?
What difference does it make if they unlink it while you have it open,
or whether they wait until the instant you close it? Either way, it's
deleted the second you close it.
Again, it's going to depend on the file system. But in the file systems
that we typically think of as "IFS file systems" (such as the root and
/QOpenSys ones) files aren't actually deleted when you unlink them.
You understand that, right? If a user runs the RMVLNK or DEL or ERASE
CL command against an object in / or /QopenSys, it will remove the
filename from the directory, but it won't actually delete the file's
data unless no jobs have the file open. (Plus, there can be no other
hard-links to the file, but that probably goes without saying.)
So if you have a file open, it can be unlinked, but you can continue to
use it without problems... the file isn't actually deleted (i.e. the
data sectors it occupies aren't marked as "unused") until you close it.
------------------------------
midrange.com
