Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
more than one copy of file open
38 views
Skip to first unread message
Jim Nagel
May 23, 2013, 1:18:09 PM5/23/13
to
Is there any way of detecting that somebody else on the network
already has a file open? It would be sensible if anybody then trying
to open the same file or document would get a read-only copy (ideally
with a message saying so).
Datapower comes with a set of modules in a folder called ClientSvr, so
that if a second user opens a given record, subsequent users see a
locked copy of that record.
Is there anything that would give the same functionality to other
applications? I'm thinking particularly of Impression at the moment,
because of the danger of changing a document without being aware it's
already open on another machine.
--
Jim Nagel www.archivemag.co.uk
>> "from" address is genuine but will change. website has current one.
already has a file open? It would be sensible if anybody then trying
to open the same file or document would get a read-only copy (ideally
with a message saying so).
Datapower comes with a set of modules in a folder called ClientSvr, so
that if a second user opens a given record, subsequent users see a
locked copy of that record.
Is there anything that would give the same functionality to other
applications? I'm thinking particularly of Impression at the moment,
because of the danger of changing a document without being aware it's
already open on another machine.
--
Jim Nagel www.archivemag.co.uk
>> "from" address is genuine but will change. website has current one.
Martin Bazley
May 23, 2013, 1:47:26 PM5/23/13
to
The following bytes were arranged on 23 May 2013 by Jim Nagel :
> Is there any way of detecting that somebody else on the network
> already has a file open? It would be sensible if anybody then trying
> to open the same file or document would get a read-only copy (ideally
> with a message saying so).
The obvious answer is to try to open it for write access. If that
returns an error, it's open.
Or if you don't want a programmatic solution and just want to know which
files are open, any number of free programs will do that for you.
Here's WimpDrain:
http://www.starfighter.acornarcade.com/mysite/utilities.htm#wimpdrain
(Although in the case of remote access - at least over ShareFS, which is
all I've got to test with - it will show the file as open if it's
located on the local machine and somebody else has opened it, or if you
were the one who opened it, but not if it's located on a remote machine
and you haven't opened it. A little logical thought shows why this
would be unrealistic to implement. Trying to open it will still fail,
however.)
--
__<^>__
/ _ _ \ It is written that Geeks shall inherit the Earth.
( ( |_| ) )
\_> <_/ ======================= Martin Bazley ==========================
> Is there any way of detecting that somebody else on the network
> already has a file open? It would be sensible if anybody then trying
> to open the same file or document would get a read-only copy (ideally
> with a message saying so).
returns an error, it's open.
Or if you don't want a programmatic solution and just want to know which
files are open, any number of free programs will do that for you.
Here's WimpDrain:
http://www.starfighter.acornarcade.com/mysite/utilities.htm#wimpdrain
(Although in the case of remote access - at least over ShareFS, which is
all I've got to test with - it will show the file as open if it's
located on the local machine and somebody else has opened it, or if you
were the one who opened it, but not if it's located on a remote machine
and you haven't opened it. A little logical thought shows why this
would be unrealistic to implement. Trying to open it will still fail,
however.)
--
__<^>__
/ _ _ \ It is written that Geeks shall inherit the Earth.
( ( |_| ) )
\_> <_/ ======================= Martin Bazley ==========================
Jim Nagel
May 23, 2013, 8:51:06 PM5/23/13
to
Martin Bazley wrote on 23 May:
> The following bytes were arranged on 23 May 2013 by Jim Nagel :
>> Is there any way of detecting that somebody else on the network
>> already has a file open? It would be sensible if anybody then trying
>> to open the same file or document would get a read-only copy (ideally
>> with a message saying so).
> ... Or if you don't want a programmatic solution and just want to know
Netsurf log and all the rest are fonts. I have an Impression file
open right here in front of me, the email file that I'm writing right
now, and a textfile from disk open in both Edit and StrongEd, but they
are not on the lists shown by Wimpdrain or Closefiles.
The Impression file is also open on two other machines on the network,
just as a test, and they are not on the WD or Closefiles lists either.
> The following bytes were arranged on 23 May 2013 by Jim Nagel :
>> Is there any way of detecting that somebody else on the network
>> already has a file open? It would be sensible if anybody then trying
>> to open the same file or document would get a read-only copy (ideally
>> with a message saying so).
> which files are open, any number of free programs will do that for you
Both Wimpdrain and Closefiles give a list of open files. One is the
Netsurf log and all the rest are fonts. I have an Impression file
open right here in front of me, the email file that I'm writing right
now, and a textfile from disk open in both Edit and StrongEd, but they
are not on the lists shown by Wimpdrain or Closefiles.
The Impression file is also open on two other machines on the network,
just as a test, and they are not on the WD or Closefiles lists either.
Ron
May 23, 2013, 10:28:22 PM5/23/13
to
In message <fedd995...@nails.abbeypress.net>
That sounds like the way it should be. Editors load a copy of the file
and only reopen the original when you use save.
I think one of Vim's things was that it can partially open large files.
This type of feature could become useful for editting the header of
a large media file.
Maybe Zap can do this, I can't remember.
Note that StrongEd can have a list of files all loaded and it can search
them all rapidly without opening and closing the original disk files for
each search.
Ron M.
and only reopen the original when you use save.
I think one of Vim's things was that it can partially open large files.
This type of feature could become useful for editting the header of
a large media file.
Maybe Zap can do this, I can't remember.
Note that StrongEd can have a list of files all loaded and it can search
them all rapidly without opening and closing the original disk files for
each search.
Ron M.
Matthew Phillips
May 24, 2013, 2:20:16 AM5/24/13
to
In message <a965705...@nails.abbeypress.net>
open in the sense of it having a current file handle, rather than whether the
content of the file appears in an editor. As Ron rightly pointed out, most
editors open the file (in the file handle sense) briefly to load the data,
and then close it, allowing other applications in the meantime to read and
write the same file. That is the problem you want addressed.
Before I turn to that, I just want to digress onto file handles, and files
being "open" in that sense, as I think it might help to get that clear. One
fundamental issue is that different filing systems have different
capabilities, and in a networked situation you might be up against any of
them.
If we talk purely about Acorn filing systems, a file can be open read-only
several times over by different applications (or indeed, multiple times by
the same application) but if it is open for read-write access then it is
impossible for it to be open read-only at the same time, and if a file is
open read-only once or more, it cannot be opened read-write.
Typically on Unix systems, however, a file can be open once read-write and
multiple times read-only simultaneously. Therefore, if your network file
system is NFS-based, it might be possible for one application to have the
file open read-write and others to then access read-only. But it depends on
the filing system's underlying rules. It's a long time since I write a RISC
OS filing system, but I don't think FileSwitch makes any assumptions as to
how the actual filing systems it talks to behave, so both behaviours are
potentially valid under RISC OS. But in my experience most developers have
chosen to make their filing systems behave like FileCore in the way that I
have just described.
What I have discussed so far is purely on the level of the file system, but
we really need to consider it on the level of the application. If you have a
document open for editing in a window, it is up to the author of the
application as to whether that document is kept open as a file during that
process. As Ron says, most do not. There are a few exceptions.
For example, !PDF keeps the file open read-only all the while, which has the
effect that you cannot rename or move a PDF if it is open in !PDF. This must
be because !PDF does not load the whole file into memory at once, and is
therefore going to need to access it again, but it could have been
implemented differently, with !PDF reopening the file whenever it needs to,
and putting up appropriate error messages if the file has been moved or
updated in the mean time.
To be honest, closing the file would be a better way to proceed: in theory
the application developer should be dealing with the file moving or changing
anyway, as (a) the file might be on a filing system which allows this to
happen, and (b) the filehandle could be closed accidentally or on purpose by
another application. So keeping a file open, in the file handle sense, is no
guarantee against Bad Things happening.
Another exception is EasiWriter, where it has the option of loading just
portions of a very large document and reading the rest as required, but it
does not keep the file open with a file handle: it reopens it as required.
So your suggestion has to be implemented at the application level, by each
application author. Some applications are already better at handling the
kind of conflicts you can get than others. If I open a text file in two
different text editors, make changes and save from one and then make changes
and save from the other, some text editors will just save and overwrite the
other edits I made. Others will spot that the date of the file about to be
overwritten is more recent than when the file was loaded, and will warn the
user. Does Impression offer this safeguard? Try experimenting, and if it
does not, that would be a sensible enhancement request. A really
sophisticated editor which spots this situation might then be able to offer
to merge the changes, if it knew what changes you had made since loading the
file.
The way this works with Microsoft Word, and the like, is that a temporary,
hidden file is placed in the same directory as the open Word document, and
other copies of Word running on other machines will examine this to see if
the file is being edited already, and who has opened it. You are then
offered the chance to open it read-only.
But all these options are application-level solutions. If Zap, say, adopted
the same arrangement to record that someone was in the process of editing a
file, then StrongEd running on another machine would only be able to detect
that the file was open in Zap if it was aware of that mechanism. OK, for
Impression that might not be such an issue, but Impression files can be
loaded by Ovation Pro, so it's not as safe as you might think!
(The other issue here is that the native RISC OS filing systems do not
have hidden files, and in addition, users are much more aware of the contents
of directories than they are on Windows, so it could get quite alarming
seeing extra files appear whenever anything is open for editing.)
So it is all rather fraught with difficulty, I fear!
--
Matthew Phillips
Durham
on 23 May 2013 Jim Nagel wrote:
> Is there any way of detecting that somebody else on the network
> already has a file open? It would be sensible if anybody then trying
> to open the same file or document would get a read-only copy (ideally
> with a message saying so).
Martin's response started off on the track of examining whether a file was
> Is there any way of detecting that somebody else on the network
> already has a file open? It would be sensible if anybody then trying
> to open the same file or document would get a read-only copy (ideally
> with a message saying so).
open in the sense of it having a current file handle, rather than whether the
content of the file appears in an editor. As Ron rightly pointed out, most
editors open the file (in the file handle sense) briefly to load the data,
and then close it, allowing other applications in the meantime to read and
write the same file. That is the problem you want addressed.
Before I turn to that, I just want to digress onto file handles, and files
being "open" in that sense, as I think it might help to get that clear. One
fundamental issue is that different filing systems have different
capabilities, and in a networked situation you might be up against any of
them.
If we talk purely about Acorn filing systems, a file can be open read-only
several times over by different applications (or indeed, multiple times by
the same application) but if it is open for read-write access then it is
impossible for it to be open read-only at the same time, and if a file is
open read-only once or more, it cannot be opened read-write.
Typically on Unix systems, however, a file can be open once read-write and
multiple times read-only simultaneously. Therefore, if your network file
system is NFS-based, it might be possible for one application to have the
file open read-write and others to then access read-only. But it depends on
the filing system's underlying rules. It's a long time since I write a RISC
OS filing system, but I don't think FileSwitch makes any assumptions as to
how the actual filing systems it talks to behave, so both behaviours are
potentially valid under RISC OS. But in my experience most developers have
chosen to make their filing systems behave like FileCore in the way that I
have just described.
What I have discussed so far is purely on the level of the file system, but
we really need to consider it on the level of the application. If you have a
document open for editing in a window, it is up to the author of the
application as to whether that document is kept open as a file during that
process. As Ron says, most do not. There are a few exceptions.
For example, !PDF keeps the file open read-only all the while, which has the
effect that you cannot rename or move a PDF if it is open in !PDF. This must
be because !PDF does not load the whole file into memory at once, and is
therefore going to need to access it again, but it could have been
implemented differently, with !PDF reopening the file whenever it needs to,
and putting up appropriate error messages if the file has been moved or
updated in the mean time.
To be honest, closing the file would be a better way to proceed: in theory
the application developer should be dealing with the file moving or changing
anyway, as (a) the file might be on a filing system which allows this to
happen, and (b) the filehandle could be closed accidentally or on purpose by
another application. So keeping a file open, in the file handle sense, is no
guarantee against Bad Things happening.
Another exception is EasiWriter, where it has the option of loading just
portions of a very large document and reading the rest as required, but it
does not keep the file open with a file handle: it reopens it as required.
So your suggestion has to be implemented at the application level, by each
application author. Some applications are already better at handling the
kind of conflicts you can get than others. If I open a text file in two
different text editors, make changes and save from one and then make changes
and save from the other, some text editors will just save and overwrite the
other edits I made. Others will spot that the date of the file about to be
overwritten is more recent than when the file was loaded, and will warn the
user. Does Impression offer this safeguard? Try experimenting, and if it
does not, that would be a sensible enhancement request. A really
sophisticated editor which spots this situation might then be able to offer
to merge the changes, if it knew what changes you had made since loading the
file.
The way this works with Microsoft Word, and the like, is that a temporary,
hidden file is placed in the same directory as the open Word document, and
other copies of Word running on other machines will examine this to see if
the file is being edited already, and who has opened it. You are then
offered the chance to open it read-only.
But all these options are application-level solutions. If Zap, say, adopted
the same arrangement to record that someone was in the process of editing a
file, then StrongEd running on another machine would only be able to detect
that the file was open in Zap if it was aware of that mechanism. OK, for
Impression that might not be such an issue, but Impression files can be
loaded by Ovation Pro, so it's not as safe as you might think!
(The other issue here is that the native RISC OS filing systems do not
have hidden files, and in addition, users are much more aware of the contents
of directories than they are on Windows, so it could get quite alarming
seeing extra files appear whenever anything is open for editing.)
So it is all rather fraught with difficulty, I fear!
--
Matthew Phillips
Durham
John Tytgat
May 24, 2013, 6:56:10 AM5/24/13
to
On 5/24/2013 8:20 AM, Matthew Phillips wrote:
> Typically on Unix systems, however, a file can be open once read-write and
> multiple times read-only simultaneously. Therefore, if your network file
> system is NFS-based, it might be possible for one application to have the
> file open read-write and others to then access read-only. But it depends on
> the filing system's underlying rules. It's a long time since I write a RISC
> OS filing system, but I don't think FileSwitch makes any assumptions as to
> how the actual filing systems it talks to behave, so both behaviours are
> potentially valid under RISC OS.
This is my understanding as well.
> Typically on Unix systems, however, a file can be open once read-write and
> multiple times read-only simultaneously. Therefore, if your network file
> system is NFS-based, it might be possible for one application to have the
> file open read-write and others to then access read-only. But it depends on
> the filing system's underlying rules. It's a long time since I write a RISC
> OS filing system, but I don't think FileSwitch makes any assumptions as to
> how the actual filing systems it talks to behave, so both behaviours are
> potentially valid under RISC OS.
John.
Martin Wuerthner
May 24, 2013, 10:22:39 AM5/24/13
to
Matthew Phillips <spam...@yahoo.co.uk> wrote:
> Another exception is EasiWriter, where it has the option of loading just
> portions of a very large document and reading the rest as required, but it
> does not keep the file open with a file handle: it reopens it as required.
No, that is not correct. If EasiWriter loads only parts of a large document,
> Another exception is EasiWriter, where it has the option of loading just
> portions of a very large document and reading the rest as required, but it
> does not keep the file open with a file handle: it reopens it as required.
it does keep the file open. It only closes the file if it has decided to
load the complete file in one go (subject to user configuration options),
and in that case it does not reopen the file.
--
Martin Wuerthner MW Software http://www.mw-software.com/
------- RISC OS Software for Design, Printing and Publishing --------
Chris Evans
May 24, 2013, 10:01:16 AM5/24/13
to
In article <a965705...@nails.abbeypress.net>, Jim Nagel
> I'm thinking particularly of Impression at the moment,
> because of the danger of changing a document without being aware it's
> already open on another machine.
It's easy for application to implement but impossible for the OS to do on
its own.
Chris Evans
--
CJE Micro's / 4D 'RISC OS Specialists'
Telephone: 01903 523222 Fax: 01903 523679
ch...@cjemicros.co.uk http://www.cjemicros.co.uk/
78 Brighton Road, Worthing, West Sussex, BN11 2EN
The most beautiful thing anyone can wear, is a smile!
<URL:mailto:jimne...@abbeypress.co.uk> wrote:
> Is there any way of detecting that somebody else on the network
> already has a file open? It would be sensible if anybody then trying
> to open the same file or document would get a read-only copy (ideally
> with a message saying so).
>
> Datapower comes with a set of modules in a folder called ClientSvr, so
> that if a second user opens a given record, subsequent users see a
> locked copy of that record.
>
> Is there anything that would give the same functionality to other
> applications?
Yes but it has to be programmed into the application itself.
> Is there any way of detecting that somebody else on the network
> already has a file open? It would be sensible if anybody then trying
> to open the same file or document would get a read-only copy (ideally
> with a message saying so).
>
> Datapower comes with a set of modules in a folder called ClientSvr, so
> that if a second user opens a given record, subsequent users see a
> locked copy of that record.
>
> Is there anything that would give the same functionality to other
> applications?
> I'm thinking particularly of Impression at the moment,
> because of the danger of changing a document without being aware it's
> already open on another machine.
its own.
Chris Evans
--
CJE Micro's / 4D 'RISC OS Specialists'
Telephone: 01903 523222 Fax: 01903 523679
ch...@cjemicros.co.uk http://www.cjemicros.co.uk/
78 Brighton Road, Worthing, West Sussex, BN11 2EN
The most beautiful thing anyone can wear, is a smile!
Matthew Phillips
May 24, 2013, 6:17:43 PM5/24/13
to
In message <mpro.mnb3xr007t...@mw-software.com>
very large file. I verified that EasiWriter's application space was too
small to contain the file and thought I checked that the file was not open,
but somewhere along the line I must have made a mistake or misinterpreted
something as I am sure you know what you are talking about.
This makes me less embarrassed about admitting that Impact keeps its database
data files open while a database is in use....
--
Matthew Phillips
Durham
on 24 May 2013 Martin Wuerthner wrote:
> Matthew Phillips <spam...@yahoo.co.uk> wrote:
>
> > Another exception is EasiWriter, where it has the option of loading just
> > portions of a very large document and reading the rest as required, but
> > it does not keep the file open with a file handle: it reopens it as
> > required.
>
> No, that is not correct. If EasiWriter loads only parts of a large
> document, it does keep the file open. It only closes the file if it has
> decided to load the complete file in one go (subject to user configuration
> options), and in that case it does not reopen the file.
My apologies: I did actually test the behaviour before I posted, and loaded a
> Matthew Phillips <spam...@yahoo.co.uk> wrote:
>
> > Another exception is EasiWriter, where it has the option of loading just
> > portions of a very large document and reading the rest as required, but
> > it does not keep the file open with a file handle: it reopens it as
> > required.
>
> No, that is not correct. If EasiWriter loads only parts of a large
> document, it does keep the file open. It only closes the file if it has
> decided to load the complete file in one go (subject to user configuration
> options), and in that case it does not reopen the file.
very large file. I verified that EasiWriter's application space was too
small to contain the file and thought I checked that the file was not open,
but somewhere along the line I must have made a mistake or misinterpreted
something as I am sure you know what you are talking about.
This makes me less embarrassed about admitting that Impact keeps its database
data files open while a database is in use....
--
Matthew Phillips
Durham
Jim Nagel
May 24, 2013, 7:40:26 PM5/24/13
to
Fireworkz (1.34/10) behaviour is interesting. Trying to open a second
copy of the same document produces the message:
"ADFS::...<filename> is already loaded"
However, another machine on the network CAN open a copy of the
document while it is still open on the first machine.
Obviously on the second machine, the prefix would be ShareFS, not
ADFS. I don't know what the mechanism is within the Fireworkz code,
but maybe if it ignored the prefix?
While a Fireworkz document is open, !Closefiles does not register it
as an open file. (I haven't tried with a very large document,
though.) This accords with what others said earlier in this thread.
copy of the same document produces the message:
"ADFS::...<filename> is already loaded"
However, another machine on the network CAN open a copy of the
document while it is still open on the first machine.
Obviously on the second machine, the prefix would be ShareFS, not
ADFS. I don't know what the mechanism is within the Fireworkz code,
but maybe if it ignored the prefix?
While a Fireworkz document is open, !Closefiles does not register it
as an open file. (I haven't tried with a very large document,
though.) This accords with what others said earlier in this thread.
David Holden
May 25, 2013, 1:42:57 AM5/25/13
to
On 25-May-2013, Jim Nagel <jimne...@abbeypress.co.uk> wrote:
> Fireworkz (1.34/10) behaviour is interesting. Trying to open a
> second
> copy of the same document produces the message:
> "ADFS::...<filename> is already loaded"
>
> However, another machine on the network CAN open a copy of the
> document while it is still open on the first machine.
type.
One instance of the program won't load the same file twice, however
another instance can. Normally this type of program won't allow you to
run 2 instances on the same machine but will often allow you 2 'views'
of the same document.
With a second copy of the program on another machine you can load the
document twice, or if you copy it to another directory on the same
machine (or just copy it with another name) you'll be able to load it
twice. There are times when this is useful, for example for DTP
programs where you've made some changes and want to check them against
the original.
--
David Holden - APDL - www.apdl.co.uk
Vince M Hudd
May 25, 2013, 5:35:10 AM5/25/13
to
Jim Nagel <jimne...@abbeypress.co.uk> wrote:
> Fireworkz (1.34/10) behaviour is interesting. Trying to open a second
> copy of the same document produces the message:
> "ADFS::...<filename> is already loaded"
This is because Fireworkz - like most similar applications - knows what it
> Fireworkz (1.34/10) behaviour is interesting. Trying to open a second
> copy of the same document produces the message:
> "ADFS::...<filename> is already loaded"
has loaded. When you double click "ADFS::...<filename>" a second time, it
just says "Oh look, the user has tried to load this file that I already have
loaded... I'll let him know."
> However, another machine on the network CAN open a copy of the document
> while it is still open on the first machine.
> Obviously on the second machine, the prefix would be ShareFS, not
> ADFS. I don't know what the mechanism is within the Fireworkz code, but
> maybe if it ignored the prefix?
mechanismin place by which another copy of Fireworkz on another machine can
be aware that the file is already loaded by the first copy - such as the
second/hidden file method that is employed by (for example) Word and other
applications on Windows.
(Of course if, like me, you have Windows set to display hidden files then
hidden is something hidden files aren't. :) Just as they wouldn't be on RISC
OS, which doesn't allow hidden files in the first place.)
--
Soft Rock Software: http://www.softrock.co.uk
Vince M Hudd: http://misc.vinceh.com/about-vinceh/
RISCOSitory: http://www.riscository.com
Theo Markettos
May 25, 2013, 12:03:14 PM5/25/13
to
Matthew Phillips <spam...@yahoo.co.uk> wrote:
> Typically on Unix systems, however, a file can be open once read-write and
> multiple times read-only simultaneously. Therefore, if your network file
> system is NFS-based, it might be possible for one application to have the
> file open read-write and others to then access read-only.
https://en.wikipedia.org/wiki/File_locking
> Typically on Unix systems, however, a file can be open once read-write and
> multiple times read-only simultaneously. Therefore, if your network file
> system is NFS-based, it might be possible for one application to have the
> file open read-write and others to then access read-only.
On Unix, most network file systems get locking semantics wrong.
Theo
Jeremy Nicoll - news posts
May 25, 2013, 7:50:01 PM5/25/13
to
Chris Evans <ch...@cjemicros.co.uk> wrote:
>In article <a965705...@nails.abbeypress.net>, Jim Nagel
><URL:mailto:jimne...@abbeypress.co.uk> wrote:
> > I'm thinking particularly of Impression at the moment, because of the
> > danger of changing a document without being aware it's already open on
> > another machine.
>
> It's easy for application to implement but impossible for the OS to do on
> its own.
The basic problem is that RISC OS wasn't designed to support this sort of
>In article <a965705...@nails.abbeypress.net>, Jim Nagel
><URL:mailto:jimne...@abbeypress.co.uk> wrote:
> > I'm thinking particularly of Impression at the moment, because of the
> > danger of changing a document without being aware it's already open on
> > another machine.
>
> It's easy for application to implement but impossible for the OS to do on
> its own.
thing. In OSes that were designed for multiple users, multiple computers
and multiple users then it does work alright.
In IBM's mainframe OSes it's done partly by the OS and partly by the disk
controller hardware. It's normal for a disk controller (with many disks
under its control) to be attached to multiple mainframes all at the same
time, and those mainframes can have hundreds or thousands of users/tasks all
of which can simultaneously access all the disks and files. What happens is
that within each OS on each single computer use of files is managed strictly
with the OS keeping lists of who wants to access what file and with what
level of access, and it doesn't let users/tasks get into conflict with each
other.
What used to happen is that when a particular OS running on one mainframe
asked the disk controller hardware to write some data somewhere on a
particular disk (on behalf of any of the users/tasks running under that OS
on that mainframe) the disk controller would briefly restrict the use of
that disk to that particular computer; I/O from other OSes/computers would
have to wait until the I/O completes.
That's not in itself a problem because the normal way of a mainframe doing
I/O is for it to package up a request for some data to be read or written,
pass that request to the I/O subsystem (which is in essence the disks,
controllers and connections, and is itself intelligent) and then go and do
something else until the I/O subsystem says "I've done it for you". So when
a particular disk is briefly unavailable to I/O requests from certain
computers the programmes wanting the data just have to wait slightly longer
than they might otherwise have done. Meantime the mainframe does other work
for other tasks.
A classic systems problem is when such a restriction doesn't get lifted
timeously and then other mainframes can't get access to that disk and
everything grinds to a halt - terminals no longer work in the branches; all
the ATMS shut, customers get annoyed, management start screaming...
(The whole thing is pretty complicated because a single mainframe could be
running multiple OSes in separate partitions all at the same time. Each OS
can have loads of users...)
When I last worked with such systems (maybe 15 years ago) vendors other than
IBM provided system software (ie add-ons to the OS) that would allow
different OSes to share the lists of what programs wanted to use which files
between them. Then every OS would be able to queue I/O requests and manage
them across the whole group of computers; it was no longer necessary for the
hardware to restrict ('reserve') a disk for use only from a single computer.
IIRC IBM was also providing hardware support for loosely coupling multiple
mainframes (so although they weren't absolutely in sync with each other,
they could cooperate). This did require very fast connections between the
hardware of each mainframe so that the OSes running on each one could share
info about who was accessing shared resources, very fast.
I recall some of this critical sharing of OS data being achieved by reading/
writing it to solid-state disks. This was, oh, maybe 25-30 years ago, long
before any PC ever had such a thing. The SSDs were extremely expensive...
--
Jeremy C B Nicoll - my opinions are my own.
Email sent to my from-address will be deleted. Instead, please reply
to newsre...@wingsandbeaks.org.uk replacing "aaa" by "284".
spampling
May 26, 2013, 5:07:09 AM5/26/13
to
In article <mpro.mnclam001...@softrock.co.uk>,
that "hidden" files aren't pale shadow icons. Hidden stuff can be a pain,
or embarrassing.
Just last week:
Our tutor requested we copy the content of a flash drive onto a machine
during a course. Should I email him and tell him the copy I took on another
flash drive includes the Mac trash files that happen to include various
personal files?
> Just as they wouldn't be on RISC
> OS, which doesn't allow hidden files in the first place.)
Aw, there's so much malware fun people can have with a hidden file or two.
Yeah, I've cleaned malware from various machines that used that little
"protection"
--
Steve Pampling
Vince M Hudd <vin...@softrock.co.uk> wrote:
> (Of course if, like me, you have Windows set to display hidden files then
> hidden is something hidden files aren't. :)
It's only when I do anything with a new isolated machine that I even recall
> (Of course if, like me, you have Windows set to display hidden files then
> hidden is something hidden files aren't. :)
that "hidden" files aren't pale shadow icons. Hidden stuff can be a pain,
or embarrassing.
Just last week:
Our tutor requested we copy the content of a flash drive onto a machine
during a course. Should I email him and tell him the copy I took on another
flash drive includes the Mac trash files that happen to include various
personal files?
> Just as they wouldn't be on RISC
> OS, which doesn't allow hidden files in the first place.)
Yeah, I've cleaned malware from various machines that used that little
"protection"
--
Steve Pampling
Russell Hafter News
May 26, 2013, 7:29:35 AM5/26/13
to
In article <5351cef3e0...@btinternet.com>, spampling
I would have thought that hidden files were much more the
spawn of the devil than certain other things under
discussion here recently.
The ability to hide files seems to be just asking for
trouble.
--
Russell
http://www.russell-hafter-holidays.co.uk
Russell Hafter Holidays E-mail to enquiries at our domain
Need a hotel? <http://www.hrs.com/?client=en__blue&customerId=416873103>
<spam....@btinternet.com> wrote:
> Our tutor requested we copy the content of a flash drive
> onto a machine during a course. Should I email him and
> tell him the copy I took on another flash drive includes
> the Mac trash files that happen to include various
> personal files?
He certtainly needs to be educated about such things.
> Our tutor requested we copy the content of a flash drive
> onto a machine during a course. Should I email him and
> tell him the copy I took on another flash drive includes
> the Mac trash files that happen to include various
> personal files?
I would have thought that hidden files were much more the
spawn of the devil than certain other things under
discussion here recently.
The ability to hide files seems to be just asking for
trouble.
--
Russell
http://www.russell-hafter-holidays.co.uk
Russell Hafter Holidays E-mail to enquiries at our domain
Need a hotel? <http://www.hrs.com/?client=en__blue&customerId=416873103>
Chris Evans
May 29, 2013, 5:01:01 AM5/29/13
to
In article <8900b8505...@sinenomine.freeserve.co.uk>, Matthew Phillips
3.02.1.24 (11 Jul 2011)
doesn't keep the file open (Well certainly not on files 3MB or less)
<URL:mailto:spam...@yahoo.co.uk> wrote:
> In message <a965705...@nails.abbeypress.net>
> on 23 May 2013 Jim Nagel wrote:
>
> For example, !PDF keeps the file open read-only all the while, which has the
> effect that you cannot rename or move a PDF if it is open in !PDF. This must
> be because !PDF does not load the whole file into memory at once, and is
> therefore going to need to access it again, but it could have been
> implemented differently, with !PDF reopening the file whenever it needs to,
> and putting up appropriate error messages if the file has been moved or
> updated in the mean time.
!PDF used to do that and I'm not sure when it changed but
> In message <a965705...@nails.abbeypress.net>
> on 23 May 2013 Jim Nagel wrote:
>
> For example, !PDF keeps the file open read-only all the while, which has the
> effect that you cannot rename or move a PDF if it is open in !PDF. This must
> be because !PDF does not load the whole file into memory at once, and is
> therefore going to need to access it again, but it could have been
> implemented differently, with !PDF reopening the file whenever it needs to,
> and putting up appropriate error messages if the file has been moved or
> updated in the mean time.
3.02.1.24 (11 Jul 2011)
doesn't keep the file open (Well certainly not on files 3MB or less)
Tony Moore
May 29, 2013, 3:00:00 PM5/29/13
to
On 29 May 2013, Chris Evans <ch...@cjemicros.co.uk> wrote:
> In article <8900b8505...@sinenomine.freeserve.co.uk>, Matthew
> Phillips <URL:mailto:spam...@yahoo.co.uk> wrote:
> > In message <a965705...@nails.abbeypress.net>
> > on 23 May 2013 Jim Nagel wrote:
> >
> > For example, !PDF keeps the file open read-only all the while, which
> > has the effect that you cannot rename or move a PDF if it is open in
> > !PDF.
[snip]
> In article <8900b8505...@sinenomine.freeserve.co.uk>, Matthew
> Phillips <URL:mailto:spam...@yahoo.co.uk> wrote:
> > In message <a965705...@nails.abbeypress.net>
> > on 23 May 2013 Jim Nagel wrote:
> >
> > For example, !PDF keeps the file open read-only all the while, which
> > has the effect that you cannot rename or move a PDF if it is open in
> > !PDF.
> !PDF used to do that and I'm not sure when it changed but 3.02.1.24
> (11 Jul 2011) doesn't keep the file open (Well certainly not on files
> 3MB or less)
PDF 3.03.1.25alpha 8 (20 May 2013).
Tony
Chris Gransden
May 29, 2013, 4:51:55 PM5/29/13
to
In article <e7bc905353.old_coaster@old_coaster.yahoo.co.uk>,
The PDF file is always kept open read only. Closing the window closes the
file.
If you keep your PDF files on a fat32 formatted drive using Fat32fs it's
possible to rename and move (even between different drives) the PDF while
open provided the filesystem is using Fat32fs.
Chris.
file.
If you keep your PDF files on a fat32 formatted drive using Fat32fs it's
possible to rename and move (even between different drives) the PDF while
open provided the filesystem is using Fat32fs.
Chris.
Tony Moore
May 30, 2013, 6:01:19 AM5/30/13
to
On 29 May 2013, Chris Gransden <chr...@care4free.net> wrote:
> In article <e7bc905353.old_coaster@old_coaster.yahoo.co.uk>,
> Tony Moore <old_c...@yahoo.co.uk> wrote:
> > On 29 May 2013, Chris Evans <ch...@cjemicros.co.uk> wrote:
> > > In article <8900b8505...@sinenomine.freeserve.co.uk>,
> > > Matthew Phillips <URL:mailto:spam...@yahoo.co.uk> wrote:
> > > > In message <a965705...@nails.abbeypress.net>
> > > > on 23 May 2013 Jim Nagel wrote:
> > > >
> > > > For example, !PDF keeps the file open read-only all the while,
> > > > which has the effect that you cannot rename or move a PDF if it
> > > > is open in !PDF.
>
> > [snip]
>
> > > !PDF used to do that and I'm not sure when it changed but
> > > 3.02.1.24 (11 Jul 2011) doesn't keep the file open (Well certainly
> > > not on files 3MB or less)
>
> > PDF 3.02.1.24 (11 Jul 2011) _does_ keep a loaded file open. So to
> > does PDF 3.03.1.25alpha 8 (20 May 2013).
>
> The PDF file is always kept open read only.
Isn't that what Matthew, and I, said?
> In article <e7bc905353.old_coaster@old_coaster.yahoo.co.uk>,
> Tony Moore <old_c...@yahoo.co.uk> wrote:
> > On 29 May 2013, Chris Evans <ch...@cjemicros.co.uk> wrote:
> > > In article <8900b8505...@sinenomine.freeserve.co.uk>,
> > > Matthew Phillips <URL:mailto:spam...@yahoo.co.uk> wrote:
> > > > In message <a965705...@nails.abbeypress.net>
> > > > on 23 May 2013 Jim Nagel wrote:
> > > >
> > > > For example, !PDF keeps the file open read-only all the while,
> > > > which has the effect that you cannot rename or move a PDF if it
> > > > is open in !PDF.
>
> > [snip]
>
> > > !PDF used to do that and I'm not sure when it changed but
> > > 3.02.1.24 (11 Jul 2011) doesn't keep the file open (Well certainly
> > > not on files 3MB or less)
>
> > PDF 3.02.1.24 (11 Jul 2011) _does_ keep a loaded file open. So to
> > does PDF 3.03.1.25alpha 8 (20 May 2013).
>
> The PDF file is always kept open read only.
> Closing the window closes the file. If you keep your PDF files on a
> fat32 formatted drive using Fat32fs it's possible to rename and move
> (even between different drives) the PDF while open provided the
> filesystem is using Fat32fs.
the Win7 file cannot be re-named or moved. If Fat32fs permits this, does
it not suggest a bug in Fat32fs?
Tony
Tony Moore
May 30, 2013, 6:13:25 AM5/30/13
to
On 30 May 2013, Tony Moore <old_c...@yahoo.co.uk> wrote:
> On 29 May 2013, Chris Gransden <chr...@care4free.net> wrote:
[snip]
> > The PDF file is always kept open read only.
>
> Isn't that what Matthew, and I, said?
Chris, sorry for that. I had thought that I was responding to Chris.
Tony
> On 29 May 2013, Chris Gransden <chr...@care4free.net> wrote:
[snip]
> > The PDF file is always kept open read only.
>
> Isn't that what Matthew, and I, said?
Tony
Tony Moore
May 30, 2013, 6:24:02 AM5/30/13
to
Tony
Chris Gransden
May 30, 2013, 6:59:06 AM5/30/13
to
In article <8d41e35353.old_coaster@old_coaster.yahoo.co.uk>,
I just tried the same thing with SunFish with an NFS mounted drive on
Linux. Renaming the file works. Moving the file to a different NFS mount
doesn't update the file handle so !PDF crashes. It is also possible to
delete the PDF file which also crashes !PDF.
> If Fat32fs permits this, does
> it not suggest a bug in Fat32fs?
I can't see that it is a bug. The file handle is updated correctly. !PDF
just carries on as normal.
Chris.
Tony Moore <old_c...@yahoo.co.uk> wrote:
> Using LanMan98, if a file, resident on Win7, is open in PDF on a RiscPC,
> the Win7 file cannot be re-named or moved.
Maybe a restriction with LanMan98.
> Using LanMan98, if a file, resident on Win7, is open in PDF on a RiscPC,
> the Win7 file cannot be re-named or moved.
I just tried the same thing with SunFish with an NFS mounted drive on
Linux. Renaming the file works. Moving the file to a different NFS mount
doesn't update the file handle so !PDF crashes. It is also possible to
delete the PDF file which also crashes !PDF.
> If Fat32fs permits this, does
> it not suggest a bug in Fat32fs?
just carries on as normal.
Chris.
Vince M Hudd
May 30, 2013, 6:55:25 AM5/30/13
to
Tony Moore <old_c...@yahoo.co.uk> wrote:
> On 30 May 2013, Tony Moore <old_c...@yahoo.co.uk> wrote:
> > On 30 May 2013, Tony Moore <old_c...@yahoo.co.uk> wrote:
[...]
> On 30 May 2013, Tony Moore <old_c...@yahoo.co.uk> wrote:
> > On 30 May 2013, Tony Moore <old_c...@yahoo.co.uk> wrote:
> > > Isn't that what Matthew, and I, said?
> > Chris, sorry for that. I had thought that I was responding to Chris.
> Try again: I had thought that I was responding to Chris Evans.
Tony Moore
May 30, 2013, 9:59:57 AM5/30/13
to
On 30 May 2013, Vince M Hudd <vin...@softrock.co.uk> wrote:
> Tony Moore <old_c...@yahoo.co.uk> wrote:
> > On 30 May 2013, Tony Moore <old_c...@yahoo.co.uk> wrote:
> > > On 30 May 2013, Tony Moore <old_c...@yahoo.co.uk> wrote:
>
> [...]
>
> > > > Isn't that what Matthew, and I, said?
> > > Chris, sorry for that. I had thought that I was responding to
> > > Chris.
> > Try again: I had thought that I was responding to Chris Evans.
>
> Bad hair day? :p
Not much hair, these days! - just confused :)
> Tony Moore <old_c...@yahoo.co.uk> wrote:
> > On 30 May 2013, Tony Moore <old_c...@yahoo.co.uk> wrote:
> > > On 30 May 2013, Tony Moore <old_c...@yahoo.co.uk> wrote:
>
> [...]
>
> > > > Isn't that what Matthew, and I, said?
> > > Chris, sorry for that. I had thought that I was responding to
> > > Chris.
> > Try again: I had thought that I was responding to Chris Evans.
>
> Bad hair day? :p
Tony
Tony Moore
May 30, 2013, 9:55:33 AM5/30/13
to
On 30 May 2013, Chris Gransden <chr...@care4free.net> wrote:
> In article <8d41e35353.old_coaster@old_coaster.yahoo.co.uk>,
> Tony Moore <old_c...@yahoo.co.uk> wrote:
>
> > Using LanMan98, if a file, resident on Win7, is open in PDF on a
> > RiscPC, the Win7 file cannot be re-named or moved.
>
> Maybe a restriction with LanMan98.
The restriction comes from Win7, which reports that
> In article <8d41e35353.old_coaster@old_coaster.yahoo.co.uk>,
> Tony Moore <old_c...@yahoo.co.uk> wrote:
>
> > Using LanMan98, if a file, resident on Win7, is open in PDF on a
> > RiscPC, the Win7 file cannot be re-named or moved.
>
> Maybe a restriction with LanMan98.
The action can't be completed because the file is open in System
LanMan98 correctly reports that the file is open, so Win7 refuses to
allow re-naming, moving, or deleting.
> I just tried the same thing with SunFish with an NFS mounted drive on
> Linux. Renaming the file works. Moving the file to a different NFS
> mount doesn't update the file handle so !PDF crashes. It is also
> possible to delete the PDF file which also crashes !PDF.
correctly, whereas Linux doesn't.
Tony
Chris Evans
May 31, 2013, 12:42:13 PM5/31/13
to
In article <53539afc...@care4free.net>, Chris Gransden
Yes, Sorry I was wrong up to a point.
I think with some/most? programs [1] once it has opened a file you can't
then say copy that file to another drive.
But with the later !PDF (And possible earlier verisions) you can. Whilst
viewing a PDF stored on my hard drive I could copy the file to my RAM Disc!
Maybe the difference between OpenIn & OpenUp and !PDF has always been as it is.
I thought I couldn't in the past do what I can now.
[1] Datapower is what I tested it on and I can't think of another to test it on.
Sorry if I've confused people.
I think with some/most? programs [1] once it has opened a file you can't
then say copy that file to another drive.
But with the later !PDF (And possible earlier verisions) you can. Whilst
viewing a PDF stored on my hard drive I could copy the file to my RAM Disc!
Maybe the difference between OpenIn & OpenUp and !PDF has always been as it is.
I thought I couldn't in the past do what I can now.
[1] Datapower is what I tested it on and I can't think of another to test it on.
Sorry if I've confused people.
0 new messages