sdflsdkj
Ralph Corderoy
I'm just about to get an Ethernet card from ebay which will initially be
in an R140 to transfer data off into disc images and then make its
permanent home in a friend's RISC PC.
From what I've seen so far, it seems to me that given a Linux server
nearby there isn't an *ideal* solution to using it as a fileserver and
accessing the files using the normal Filer windows under RISC OS.
You can either have the RO machine as a SMB server, but that puts the
data in the wrong place. Using LanMan98/Omniclient/SMBclient all lose
some of the RO file attributes, the main one they keep being the
filetype if I understand correctly. FTPc doesn't provide a seemless
`ftpfs' Filer interface.
Out of the various Acorn proprietary network filesystem protocols, e.g.
Level 4 Fileserver, Access+, etc., of which I know extremely little,
what ones cope with the long filenames and other features, if there are
any, of modern RO filesystems? Have they kept pace?
Next question. Since these presumably maintain an exact set of data
suitable for RO since the server is normally RO too, could a program
running on Linux act as a server or peer, pretending to be another RO
machine? The program could use whatever method it wanted to store the
files' meta-data providing a complete storage of RO file attributes.
And don't all RO machine from 3.10 come with NetFS as standard? So
extra programs like Omniclient wouldn't be required on the RO side?
What documentation exists for Acorn's proprietary file transfer
protocols? Ideally, it would be a TCP/IP based one of course.
Cheers,
--
Ralph Corderoy. http://inputplus.co.uk/ralph/ http://troff.org/
Ralph Corderoy
Ralph.
Michael Gilbert
<URL:mailto:ra...@inputplus.co.uk> wrote:
[snip]
> Out of the various Acorn proprietary network filesystem protocols, e.g.
> Level 4 Fileserver, Access+, etc., of which I know extremely little,
> what ones cope with the long filenames and other features, if there are
> any, of modern RO filesystems? Have they kept pace?
Access filenames are determined by the OS version on the machine doing
the sharing. If you share a directory on an RO4 box, you can have long
filenames on RO3.11 (Although they won't display correctly in filer
windows). Conversely, a Share from a RISC OS 3 box will not accept a
long file name saved from a RISC OS 4 one.
The Level 4 Fileserver creaked a decade ago. The Advanced Level 4
fileserver might have been usable had there been hardware that could
cope with the demands of the Manager application.
Acorn ceased investing in server software, and chose to develop a
universal client application instead. This would then allow customers to
choose the appropriate server architecture, be it Windows NT or UNIX (or
Acorn, or even Apple, in theory). They called this application
OmniClient. It's flexible enough for third parties to write alternative
client modules. The best known of these is LanMan98.
>
> Next question. Since these presumably maintain an exact set of data
> suitable for RO since the server is normally RO too, could a program
> running on Linux act as a server or peer, pretending to be another RO
> machine? The program could use whatever method it wanted to store the
> files' meta-data providing a complete storage of RO file attributes.
> And don't all RO machine from 3.10 come with NetFS as standard? So
> extra programs like Omniclient wouldn't be required on the RO side?
>
> What documentation exists for Acorn's proprietary file transfer
> protocols? Ideally, it would be a TCP/IP based one of course.
>
Access and NetFS can exist in TCP/IP environments, but it seems silly to
expend time and effort on reinventing the wheel. Your Linux box has or
can have a SAMBA server, LanMan98 will talk to it.
--
Michael Gilbert: in his own write
MALIGNITY
Ralph Corderoy
Thanks for some background on the Acorn server technologies.
> Access and NetFS can exist in TCP/IP environments, but it seems silly
> to expend time and effort on reinventing the wheel. Your Linux box has
> or can have a SAMBA server, LanMan98 will talk to it.
But, Samba on Linux plus LM98 won't preserve all the meta-data. Or does
LM98 store that in private files on the server?
Is there information on the Access+ protocol available?
alan.calder
Michael Gilbert <mgil...@eclipse.co.uk> wrote:
> The Level 4 Fileserver creaked a decade ago. The Advanced Level 4
> fileserver might have been usable had there been hardware that could
> cope with the demands of the Manager application.
Could you expand on that last bit? Ours is hardly under pressure anymore
but is still going fine and is so easy to use compared to the wonders of
Connect Level 3.X! Hardware never seemed to be a limiting factor.
Cheers
Alam
--
Alan Calder, Milton Keynes, UK.
Jess
ra...@inputplus.co.uk (Ralph Corderoy) wrote:
> > Access and NetFS can exist in TCP/IP environments, but it seems silly
> > to expend time and effort on reinventing the wheel. Your Linux box has
> > or can have a SAMBA server, LanMan98 will talk to it.
>
> But, Samba on Linux plus LM98 won't preserve all the meta-data. Or does
> LM98 store that in private files on the server?
If the correct filetype cannot be worked out from a file extension, than
lanman98 adds ,xxx to the name on the remote system to store it.
I'm not aware of it using any extra files.
The only other thing I'm aware of is that there is mapping of the file
attributes, which caused a problem with cdburn creating ISO images
direct from a windows share. (one of the attributes when set caused the
first character of a filename to be set to !)
--
Jess icq: 91353267 msn: phant...@hotmail.com http://www.kentwebnet.com
Hotmail is my spam trap - don't use for email
RISC OS 4.33 SA233T 144+2M Castle Storm DMA + 17GB 586-133 Smoothwall
Ralph Corderoy
> If the correct filetype cannot be worked out from a file extension, than
> lanman98 adds ,xxx to the name on the remote system to store it.
OK, I'm aware of it using the filename to store the filetype meta-data.
> The only other thing I'm aware of is that there is mapping of the file
> attributes, which caused a problem with cdburn creating ISO images
> direct from a windows share. (one of the attributes when set caused
> the first character of a filename to be set to !)
That's precisely the kind of thing I want to avoid. My use isn't
accessing centrally stored files. What I'm after is 100% complete
provision of the meta-data just as if I was storing it on a local ADFS
hard disc. Performance isn't a particular issue.
Theo Markettos
> Hi Jess,
>
>> If the correct filetype cannot be worked out from a file extension, than
>> lanman98 adds ,xxx to the name on the remote system to store it.
>
> OK, I'm aware of it using the filename to store the filetype meta-data.
The ,xxx notation doesn't preserve untyped files correctly. I think LanMan
(aka the original Omniclient) will store the load/exec addresses in a
RISCOS.EA file in each directory - maybe LM98 will do the same? The one
thing even RISC OS is very bad at is copying directory datestamps -
FilerAction copies lose them. I've used a custom bit of BASIC to do
recursive copying in the past to ensure RO doen't muck around with them.
Probably a silly idea, but are the files small enough that you could zip
them up, then access the zipfiles from a share using SparkFS?
Theo
Michael Gilbert
PhotoDesk file, or whatever from a RISC OS box onto a share on an NT
server, the client copes just as well as if it were a local drive.
LanManFS does this by bodging stuff into a file called RISCOS/EA,
LanMan98 by way of the MimeMap file.
Having said that, LanMan98 has the "NoTypes" switch. With this set to
"Y", saving a RISC OS file with no extension gives a DOS-typed file with
the original name. Setting it to "N" retains the RISC OS filetype, and
appends the relevant extension as per the MimeMap file.
At a guess, because I'm way out of my depth, keeping RISC OS filetypes
without either of the above methods is what you want, and has been put
into the "Too Hard" tray by people who've looked at it before.
Michael Gilbert
Manager always seemed to take about a week to open its window, and the
RiscPC can't get data off its hard drive fast enough to make it a usable
fileserver on a large network.
Connect is a pointless way of paying lots of money for stuff you don't
need. The added complexity is probably there to make it seem worth the
shekels. IMHO, of course (:-)
Michael Gilbert
<URL:mailto:ra...@inputplus.co.uk> wrote:
> Hi Michael,
>
> Thanks for some background on the Acorn server technologies.
>
> > Access and NetFS can exist in TCP/IP environments, but it seems silly
> > to expend time and effort on reinventing the wheel. Your Linux box has
> > or can have a SAMBA server, LanMan98 will talk to it.
>
> But, Samba on Linux plus LM98 won't preserve all the meta-data. Or does
> LM98 store that in private files on the server?
Okay, confession of ignorance time. What's meta-data? Why do you need
it? If NC systems can operate happily with all data stored on NT Server
boxes and accessed by LanManFS or LanMan98, why is neither of the
clients suitable for your needs?
>
> Is there information on the Access+ protocol available?
>
Access is the protocol, Access+ some twiddly bits around the outside.
Or, possibly, UDP is the protocol, with a little help from Freeway and
ShareFS. From the Services file supplied with the ANT Suite:
# Acorn-specific services
#
aun-data 32768/udp
aun-atp 32769/udp
freeway1 32770/udp
freeway2 32771/udp
sharefs 49171/udp
alan.calder
Michael Gilbert <mgil...@eclipse.co.uk> wrote:
> In article <4bae714be2...@argonet.co.uk>, alan.calder
> <URL:mailto:alan....@argonet.co.uk> wrote:
> > In article <ant01230...@riscpc.local>,
> > Michael Gilbert <mgil...@eclipse.co.uk> wrote:
> > > The Level 4 Fileserver creaked a decade ago. The Advanced Level 4
> > > fileserver might have been usable had there been hardware that could
> > > cope with the demands of the Manager application.
> >
> > Could you expand on that last bit? Ours is hardly under pressure anymore
> > but is still going fine and is so easy to use compared to the wonders of
> > Connect Level 3.X! Hardware never seemed to be a limiting factor.
> Manager always seemed to take about a week to open its window, and the
> RiscPC can't get data off its hard drive fast enough to make it a usable
> fileserver on a large network.
> Connect is a pointless way of paying lots of money for stuff you don't
> need. The added complexity is probably there to make it seem worth the
> shekels. IMHO, of course (:-)
Thanks for the response, Michael.
Never seemed to have the slow opening problem, though on an A5000 there
could be memory problems if more than one file-server was being looked at
at once.
As for server speed the RPC used, even the A5000 still in use (10 years
old now I think!), was OK. Maybe this was largely because the fileservers
were only used for users' data with everything else being handled either
by a group of Nexus file-sharers or in the case of the RPCs running
everything off the big (!) harddisks.
Cheers
Alan
druck
> Ralph Corderoy <ra...@inputplus.co.uk> wrote:
>> Hi Jess,
>>
>>> If the correct filetype cannot be worked out from a file extension, than
>>> lanman98 adds ,xxx to the name on the remote system to store it.
>>
>> OK, I'm aware of it using the filename to store the filetype meta-data.
>
> The ,xxx notation doesn't preserve untyped files correctly.
Thats what the ,lllllllleeeeeeee notation is for.
> I think LanMan (aka the original Omniclient) will store the load/exec
> addresses in a RISCOS.EA file in each directory - maybe LM98 will do the
> same?
It doesn't use that. Its an ambonable system that restricts you to 10
character filenames and denies use of the files from any other operating
system. May it for ever been consigned to the bowls of hell.
> The one thing even RISC OS is very bad at is copying directory datestamps -
> FilerAction copies lose them. I've used a custom bit of BASIC to do
> recursive copying in the past to ensure RO doen't muck around with them.
The directory date stamps are not important. Application directory date
stamps shown by the filer come from the !RunImage file.
---druck
--
The ARM Club * http://www.armclub.org.uk/
Alan Williams
I made a bit of a start on a writing a netfs server in C having once
before written one in basic, the plan was that it would be portable.
The benefit of this is that you don't have to buy any client software,
netfs client has tended to be built in to RISC OS. This really means
'use some other platform as a Level 4 server' Obviously this probably
means only over ethernet as not many 'other' platforms have Econet.
However this is the sixth year of below average rain fall over here.
Suitable days have been in short supply. Unlike !awServer netfssrvr
aimed to expose the underlying OS rights and ownership models, rather
than attempt to provide the L2/L3/Filestore kind of view. The project
is probably moth balled at the moment as I don't have a working second
machine to be a AUN client.
Ben Harris
Ralph Corderoy <ra...@inputplus.co.uk> wrote:
>Out of the various Acorn proprietary network filesystem protocols, e.g.
>Level 4 Fileserver, Access+, etc., of which I know extremely little,
>what ones cope with the long filenames and other features, if there are
>any, of modern RO filesystems? Have they kept pace?
The only one I know about is the original Econet file server protocol (as
implemented by NetFS and Level 4), and last time I looked it couldn't
handle names longer than ten characters or files bigger than sixteen
megabytes.
>Next question. Since these presumably maintain an exact set of data
>suitable for RO since the server is normally RO too, could a program
>running on Linux act as a server or peer, pretending to be another RO
>machine?
I did hack up a read-only server for NetFS (for booting NetBSD/acorn26)
called "aund" to run on NetBSD, and it's kicking around in the NetBSD
"othersrc" CVS module. I can't seem to find a tarball on ftp.netbsd.org at
the moment, but I can create one if someone wants. It has the ability to
store load/exec addresses, though not in the same format as anyone else yet
(it also does ,fff type filetypes).
>The program could use whatever method it wanted to store the
>files' meta-data providing a complete storage of RO file attributes.
>And don't all RO machine from 3.10 come with NetFS as standard?
I think NetFS has been there since Arthur, but if you want to use it over
IP you need something slightly new. 3.11 certainly works.
>So extra programs like Omniclient wouldn't be required on the RO side?
That's precisely why I wrote aund.
>What documentation exists for Acorn's proprietary file transfer
>protocols?
ISTR that the RISC OS 3 PRMs are quite good on the NetFS protocol, though I
actually worked mostly from various older documents (some from the pre-BBC
days), because I didn't have the PRMs when I wrote aund.
--
Ben Harris
Unix Support, University of Cambridge Computing Service.
If I wanted to speak for the University, I'd be in ucam.comp-serv.announce.
Andrew Veitch
> Access is the protocol, Access+ some twiddly bits around the outside.
> Or, possibly, UDP is the protocol, with a little help from Freeway and
> ShareFS.
Access is, as far as I can tell, the name given to the combination of the
Freeway and ShareFS implementations. Freeway uses UDP/IP to advertise
resources (not necessarily ShareFS ones) around a subnet using UDP broadcasts.
As far as I can tell, the reason for the two ports listed in the Services
file is for authenticated and non-authenticated resources, such that with
the correct software on your RISC OS network gateway, protected resources
can be made available outside the immediate subnet, whereas non-protected
resources remain within the subnet only.
If I recall correctly, Access+ was Access with the ability to offer the
facility to have authenticated shares - though this may just have been the
frontend software (I seem to recall the protocol allowed for authentication
before the frontend did).
ShareFS uses Freeway to advertise the various shares it has, which are then
accessed using UDP/IP in a rather quaint fashion. I have done some work on
looking at the ShareFS protocol, although it's nowhere near complete at the
moment. Again, another project on the back burner due to lack of time and
resources. If anyone wants to persue this further, please let me know.
--
Andrew Veitch mailto:a...@visn.co.uk
Vision Internet Services http://www.visn.co.uk/
(Speaking personally)
Chris Evans
> In article <1124.3e12...@blake.inputplus.co.uk>, Ralph Corderoy
> <URL:mailto:ra...@inputplus.co.uk> wrote:
> [snip]
> > Out of the various Acorn proprietary network filesystem protocols, e.g.
> > Level 4 Fileserver, Access+, etc., of which I know extremely little,
> > what ones cope with the long filenames and other features, if there are
> > any, of modern RO filesystems? Have they kept pace?
>
> Access filenames are determined by the OS version on the machine doing
> the sharing. If you share a directory on an RO4 box, you can have long
> filenames on RO3.11 (Although they won't display correctly in filer
> windows). Conversely, a Share from a RISC OS 3 box will not accept a
> long file name saved from a RISC OS 4 one.
If the RO3 computer is running Longfilenames then you can save a longfile
named file across access from another computer (any version OS) to the RO3
machine.
Chris Evans
--
CJE Micro's / NCS / Fourth Dimension '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, UK.
lady...@gmail.com
2)VERIZON LG ZONE 4 WIT SERVICE INCLUDED...$75 obo
3)Pen wit camera in inside...$40obo
**Everything For $200**