deleting in use datafiles
James A. Williams
enqueued when in use. This would prevent any user from deleting the
file while it was being used.
In UNIX (Solaris 2.8, have not tried on HP or UNIXWARE boxes that I
have access to) ) I have noticed that an Oracle datafile can be used
and anyone in the OINSTALL or DBA group (depends on how it was
installed) can delete the file while in use.
Do any of the various UNIX's have the old mainframe enqueing on files
that would prevent such?
Paul Pluzhnikov
> Originally my career started in mainframes. A dataset (file) would be
> enqueued when in use. This would prevent any user from deleting the
> file while it was being used.
>
> In UNIX (Solaris 2.8, have not tried on HP or UNIXWARE boxes that I
> have access to) ) I have noticed that an Oracle datafile can be used
> and anyone in the OINSTALL or DBA group (depends on how it was
> installed) can delete the file while in use.
And this is a problem because?
>
> Do any of the various UNIX's have the old mainframe enqueing on files
> that would prevent such?
To my knowledge all UNICes follow the same (original UNIX) semantics:
If an application opens a file, the reference count on its inode
is incremented. Every 'delete from disk' operation removes a directory
entry and decrements the reference count by 1. So does a 'close'.
When inode reference count drops to 0, file data is deleted from disk.
If the original file had just one directory entry, its refcount would
be 2 after application has opened it, and would drop to 1 when the file
is deleted from disk.
Thus the file data will stay on disk, and no brain-damaged "enqueueing"
is needed. [Win32 also does this, which causes no end of grief in porting
UNIX programs.]
Cheers,
--
In order to understand recursion you must first understand recursion.
those who know me have no need of my name
>Originally my career started in mainframes. A dataset (file) would be
>enqueued when in use. This would prevent any user from deleting the
>file while it was being used.
>Do any of the various UNIX's have the old mainframe enqueing on files
>that would prevent such?
trick answer, sort of: z/os.
in general: no.
--
bringing you boring signatures for 17 years
p...@icke-reklam.ipsec.nu
No.
In unix the filesystem is layered.
A file has one property, an index into a inode table. Here everything about
the file ( dates, sizes, owner, permissions etc) is described. This is also
what a "filedescriptor" "points to".
The second layer is a naming scheme, where other files ( directories)
assosiates a name with one specific inode. This is mostly a one-way
association, where any number of directories may refer to the same inode.
The only thing that is stored in the inode about this relations is a
"reference count" where each directory and each open filedescriptor
has one point. When the score is zero the inode is "erased" ( all datablocks
are returned to free pool).
An open oracle file that has it's directory entry removed still has one
point; the open descriptor. When the file is closed it's erased.
This two-layer approach gives unix a unique ability to separate the names
from the file. It also gives the opportunity to create temporary files
that is guaranteed to be removed when the process terminates.
It's also the mechanism where links are made of. Every link is just
another directory entry. No link is "better" then any other link, and
nothing can be done with directory names to bypass security.
MVS has no filesystem, it's more like a primitive FAT ( say "master catalogue")
instead various add-on products will make it usable.
--
Peter Håkanson
IPSec Sverige ( At Gothenburg Riverside )
Sorry about my e-mail address, but i'm trying to keep spam out,
remove "icke-reklam" if you feel for mailing me. Thanx.
Chris Thompson
[...]
[... good description of the Unix two-layer filing sytem semantics snipped ...]
[...]
>
>MVS has no filesystem, it's more like a primitive FAT ( say "master catalogue")
>instead various add-on products will make it usable.
That's way over the top: just because it doesn't have Unix semantics doesn't
mean that it is "not a filesystem". Also there _are_ two layers in the MVS
filing system (catalog vs. VTOC); it's just that the break comes at a much
less useful place (although one can make use of it for nefarious purposes
on occasion).
In the (admittedly rare) cases when one really _does_ want to lock an
instance of a file against simultaneous update, it's Unix's flock/lockf
implementations that look like the afterthought that they are.
Summary: comp.unix.internals is not the place for Unix chauvinism, IMNSHO.
Chris Thompson
Email: cet1 [at] cam.ac.uk
Tony Finch
>
>Originally my career started in mainframes. A dataset (file) would be
>enqueued when in use. This would prevent any user from deleting the
>file while it was being used.
>
>that would prevent such?
The BSDs have some extra file flags in addition to the traditional
Unix modes. Some of these flags prevent (to various degrees) the
deletion of files. See http://www.freebsd.org/cgi/man.cgi?query=chflags
for more details.
Tony.
--
f.a.n.finch <d...@dotat.at> http://dotat.at/
LUNDY FASTNET IRISH SEA SHANNON: WEST OR SOUTHWEST 3 OR 4, OCCASIONALLY 5.
OCCASIONAL DRIZZLE. MODERATE OR GOOD, OCCASIONALLY POOR.
Simon Marchese
> Originally my career started in mainframes. A dataset (file) would be
> enqueued when in use. This would prevent any user from deleting the
> file while it was being used.
<snip>
Can anyone point me to a description of "enqueueing"? I don't quite
understand what the implication of it is here.
p...@icke-reklam.ipsec.nu
> In article <ahhsog$3i6$1...@nyheter.crt.se>, <p...@icke-reklam.ipsec.nu> wrote:
> [...]
> [... good description of the Unix two-layer filing sytem semantics snipped ...]
> [...]
>>
>>MVS has no filesystem, it's more like a primitive FAT ( say "master catalogue")
>>instead various add-on products will make it usable.
> That's way over the top: just because it doesn't have Unix semantics doesn't
> mean that it is "not a filesystem". Also there _are_ two layers in the MVS
> filing system (catalog vs. VTOC); it's just that the break comes at a much
> less useful place (although one can make use of it for nefarious purposes
> on occasion).
Ok, i'll admit that MVS has no filesystems in the UN*X sense ( or VMS MPE
or some other comparartions). It's certenly viable for the
things it's used to in an MVS environment, at least combined with
add-on products to enable partitioned datasets.
The original questions was from a user that was used to the 'MVS' way
of sort of "locking" a file, thereby preventing someone from
deleting it. The user was further using a kind of un*x, and
therefore seeking a comparation between "the un*x way and the mvs way")
My answer was that since a unix file by default is prevented from
removing as long as any directory entries or open filedescriptors
was referring to the file it is prevented from deleting (the data).
This is since the data lives a life independent from the nameing scheme.
And in un*x a file may be opened via an arbitrary number of
filenames, the two layered design of the un*x filesystem makes
this possible.
Concurrency of fileusage has to be done 'the un*x way" if good
products should be done under un*x.
Again, i'm fully aware about environments where other rules exists.
> In the (admittedly rare) cases when one really _does_ want to lock an
> instance of a file against simultaneous update, it's Unix's flock/lockf
> implementations that look like the afterthought that they are.
Correct ( on all said about unix locking). They do however fill
it's need when locking is needed. And the issue was "how to
prevent deletion of the entore file" not "update".
Most fileoperations in unix is done under the assumption that
all processes with proper rights would always be allowed to
access the data.
> Summary: comp.unix.internals is not the place for Unix chauvinism, IMNSHO.
In contrast, it's a good place for un*x information spreading.
> Chris Thompson
> Email: cet1 [at] cam.ac.uk
--