Google Answers Logo
View Question
Q: UNIX and Windows NT file access ( Answered 5 out of 5 stars,   0 Comments )
Subject: UNIX and Windows NT file access
Category: Computers > Operating Systems
Asked by: jayt2702-ga
List Price: $50.00
Posted: 19 May 2002 20:19 PDT
Expires: 26 May 2002 20:19 PDT
Question ID: 17003
how do UNIX and Windows NT handle concurrent access to files in a
distributed environment 

Clarification of Question by jayt2702-ga on 19 May 2002 20:21 PDT
Any diagrams would be fantastic, but technical detail is essential. Thanks.

Request for Question Clarification by larre-ga on 19 May 2002 23:13 PDT
In order to get you the answer you're looking for, could you be more
specific about the type and amount of detail you need? Token
Management (the Linux term) level?  Do you want a technical
explanation of how the process works in an NT server environment, plus
an explanation of the same process as handled by a Linux server, plus
a trace of the request/answer paths for the possible scenarios (Linux
server: Linux file requested by Linus system, Linus server: Linux file
requested by NT system, and the other permutations available)? Or are
you asking for an explanation of how routers handle the process of
accessing and distributing files under those environments?


Clarification of Question by jayt2702-ga on 20 May 2002 02:09 PDT
Larre - Thank you for your response.

I am specifically looking at how UNIX handles two or more people
accessing the same file. Maybe one is reading it and another is
writing to it? Or maybe a few people are reading the file
concurrently? Or possibly a few people are trying to write to the file
concurrently. How does Unix handle this?

From a distributed systems perspective, those "people" accessing the
files could easily be two remote workstations accessing a NFS
Filestore or something similar.

I would also like to know how Windows NT would handle this in a
similar scenario.

There is no need to worry about Windows NT accessing UNIX or
vies-versa. I am only looking at UNIX and WinNT as separate systems in
separate scenarios.

I hope this has clarified it a bit. If you need more information,
please do not hesitate to ask.

Thank you for your help.
I look forward to hearing from you.
Best Regards

Clarification of Question by jayt2702-ga on 20 May 2002 02:14 PDT
Larre - Sorry I forgot to mention:

I need the explanation down to the level of detail of the OS, ie I am
aware that Windows NT uses "Transactions" [I think :)] to manage it's

I am basically looking at how the system cope with multiple
reads/writes to the same file, but without going in to the detail of
how the actual data is physically stored on disk. Basically detail
just to the OS level, not the hardware level.

I hope this is ok.
Again, many thanks.
Subject: Re: UNIX and Windows NT file access
Answered By: bookface-ga on 20 May 2002 04:58 PDT
Rated:5 out of 5 stars
Both of the OSes handle this problem in the same way, though it is
implemented slightly differently. Both use the same system for
multiple programs that run concurrently, whether under one user or
multiple users.

Basically, programs declare that they want to use a file by a process
known as locking the file; there are two forms of locking a file, read
and write, and both can be done in either exclusive or shared mode.
Their declaration is put in the file descriptor, which is where
information about the file is stored and accessed.

Generally it is preferred to use the shared mode of locking, called
'advisory locking' under *nix systems, versus the exclusive form of
locking, termed 'mandatory locking' in *nix.

These modes are just as they sound; shared or advisory locking merely
indicates that the file is in use and involved in some program or
another; shared locks increment a counter in the file descriptor, and
leave it up to the next program trying to establish a lock to the file
to process this information if it chooses (for instance, by waiting
until all other programs have finished working with the file, or by
declaring another shared lock on the file).

Exclusive/Mandatory locking requires that no other programs access the
file during the time the lock is established; it is generally
unnecessary for files like documents, but it could be a vitally
important distinction, for system libraries in Windows for example. If
a write lock is established in this mode, no other program may write
to it; if a read lock is established this way, no other programs may
read from the file concurrently. When this happens, other processes
may stop and wait, checking every once in a while, when they see the
mandatory lock flag is set; or they can just give up on the file and
return some sort of an error or message to the user.

As a side note, Windows locking does not check properly for file
permissions before attempting to lock a file, only when actually
reading/writing data to the file. This presents a security risk, as a
malignent program could conceivably block access to all files on the
disk by locking them exclusively.
See the last link below for details.

As another aside, there is an alternative form of locking available
under Windows, described in detail in the second link.

"There are two types of locking mechanisms: mandatory and advisory.
Mandatory systems will actually prevent read()s and write()s to file.
Several Unix systems support them. Nevertheless, I'm going to ignore
them throughout this document, preferring instead to talk solely about
advisory locks. With an advisory lock system, processes can still read
and write from a file while it's locked. Useless? Not quite, since
there is a way for a process to check for the existence of a lock
before a read or write. See, it's a kind of cooperative locking
system. This is easily sufficient for almost all cases where file
locking is necessary."

"With Exclusive Oplock, if a file is opened in a non-exclusive (deny
none) mode, the redirector requests an opportunistic lock of the
entire file. As long as no other process has the file open, the server
will grant this oplock, giving the redirector exclusive access to the
specified file. This will allow the redirector to perform read-ahead,
write-behind, and lock caching, as long as no other process tries to
open the file.

When a second process attempts to open the file, the original owner
will be asked to Break Oplock or Break to Level II Oplock. At that
point, the redirector must invalidate cached data, flush writes and
locks, and release the oplock, or close the file.

Opportunistic Locking level II, provides a method for granting read
access to a file by more than one workstation, and these workstations
can cache read data locally (read-ahead). As long as no station writes
to the file, multiple stations can have the file open with level II


"Applications can lock the file after file descriptor is open by
application (or in the open() call itself). Usually there are two
modes for locking - SHARED and EXCLUSIVE. A single application can put
the EXCLUSIVE lock on a file. If file is locked exclusively, no
further locks can be put on the file by any another process. The main
problem of the file locking mechanism is that it does not check for
any file permissions or the mode the file is opened with before
locking is done. This makes it possible for an application with
read-only (Under privileged) access to a file to lock it exclusively.
The way file locks interfere with file access depends on the
particular OS. There are two possible situations: moderate and
non-moderate file locks. *BSD and Linux use non-moderate locking,
while Windows NT locking is moderate. What does it mean? Under UNIX,
file locking is only checked when another application tries to lock
the file. If the application does not use file locking, it will not be
affected by file locking. Under Windows, things are different. If one
application exclusively locks the file, another application cannot
access this file even if it does not try to lock the file. This should
be treated as a design flaw, because the mechanism for file locking
needs to interact security mechanism and verify the application's
files permissions.
This means that many security critical mechanisms under Windows can be
DoS'ed by file locking."

Finally, here's how it's handled with Python under Windows, very
similarly to the 'flock' method under Unix:

Search Strategy:

Hope this was helpful. Please ask for clarification if necessary.

- bookface

Request for Answer Clarification by jayt2702-ga on 20 May 2002 10:11 PDT
Thank you for the info, it is absolutely fantastic. Please can you
clarify how this information relates to a distributed environment.

Also, I would be very very greatful if you could provide any links to
any diagrams showing the locking process?

Thank you again for your help

Clarification of Answer by bookface-ga on 21 May 2002 04:05 PDT
You asked how this applies to a distributed environment; the answer is
that the files are accessed the same way, no matter how they are
called for, by multiple users or one user. *nix systems are focused on
the multiuser aspect more so than Windows machines, but again in both
cases (Windows NT following the lead of the first-gen *nix machines,
as it does in many aspects of its networking protocols) they are
accessing the file the same way. Wherever the file is being stored,
locally or remotely, there is a file descriptor that contains
information about the file such as the size, date of creation/last
modification/last access, and more relevently, the number of locks on
the file of each type. If there is an exclusive lock, access to the
file is denied; if there is a shared lock, the counter is incremented.

There aren't going to be many diagrams of this available; I don't know
that it can really be diagrammed, even, as it is not a very
visually-oriented concept. I will try to explain it as simply as I
can, though, and present the diagrams I do find.

The OS keeps track of all the processes and cycles through each one
with the allotted amount of CPU time, while the file locks are kept
track of on the disk with the directory listing of the file.
Multi-tasking OSes cycle through all the processes giving each a
certain amount of CPU time, sometimes modified by a priority code,
which is kept with the information about the process.

Each process or program, when it is actively being processed, can
establish a lock on a file, if the file is not already exclusively
locked. If it is successful in locking the file, the counter (on the
disk, with the other information about the file) is incremented. If it
is not successful, i.e. an exclusive lock is needed or requested and
the file is being used by other processes, then either the file is
given up on and an error message is returned, or the request is just
deferred and each time the processor cycles back to the program
requesting the lock it checks again to see if the file is free.

There is only one diagram of processes accessing a file I could find,
though it is techincally for QNX, a POSIX-complient system (not quite
Unix, but generally speaking, the same concept--closer to UNIX than
Linux is):
[Two processes open the same file, one linking to it twice]

NOTE: I should point out for this diagram a simplification I was
trying to make; the processes keep copies of the file descriptor
themselves, which is what this diagram shows. You can ignore this for
your purposes--all that is important is that the file is being

A real-world example regarding the use of Perl on databases, as well
as a simple text diagram, can be found at:
though the content is fairly clear, the diagram is not very well
explained. P1 is trying to access the file to write to it, which
requires a lock to the file that cannot be processed until no other
programs are using it; p2, p3, p4, and p5 are making requests to the
file at varying durations and at varying times, but p1 is blocked from
access, because it cannot do its work simultaneous to the other

Since this system is not very effective if writes need to be
preformed, the solution is a new implementation of the locking
procedures, wherein programs that need to read a file regularly over a
long duration do NOT keep open locks to files, but rather poll them
and have a seperate database to keep track of changes. Effectively the
data is transferred the same way, but the files are kept free for use
with much shorter lock times, the cost of this being an increase in
processing power and memory required.

It should be noted that this example is NOT involving any new forms of
locking; rather, it shows how the forms of locking given above can be
cleverly manipulated to produce whatever results are desired.

Another diagram:

Additionally, I thought this restatement of the above in terms of
programming in C (though the description in the first few paragraphs
is non-language specific) might be useful:

A diagram showing the possible process states in QNX--the diagram
includes various states that the program might enter while waiting for
(if down, use

A set of slides (text) from a class on distributed file systems:
Relevant information about processes, though no information about file
Other slides:

Also, I thought you might be interested in this PDF file, where
BlueArc explains its Si7500 Storage System, which allows native access
from Windows and UNIX clients to the same files, and explains why this
is a security issue: the interaction between the two systems is often
grafted on, and the file locking modes are mapped out onto each other
without replicating functionality exactly.

Hope this clears things up.

Clarification of Answer by bookface-ga on 21 May 2002 04:11 PDT
Search strategy:


Request for Answer Clarification by jayt2702-ga on 26 May 2002 17:15 PDT
bookface-ga, thank you so much for your help.
Your assistance has been very greatfully recieved. You have saved me hours!

I hope our paths cross again in the future.
My very best regards

Clarification of Answer by bookface-ga on 27 May 2002 04:34 PDT
It was a pleasure working with you as well. 

Thank you for choosing Google! Answers.
jayt2702-ga rated this answer:5 out of 5 stars
Fantastic! Researcher was fast, friendly and really helpful. I am very
very greatful. I could not of asked for a better service. Thanks!

There are no comments at this time.

Important Disclaimer: Answers and comments provided on Google Answers are general information, and are not intended to substitute for informed professional medical, psychiatric, psychological, tax, legal, investment, accounting, or other professional advice. Google does not endorse, and expressly disclaims liability for any product, manufacturer, distributor, service or service provider mentioned or any opinion expressed in answers or comments. Please read carefully the Google Answers Terms of Service.

If you feel that you have found inappropriate content, please let us know by emailing us at with the question ID listed above. Thank you.
Search Google Answers for
Google Answers  

Google Home - Answers FAQ - Terms of Service - Privacy Policy