CD won't eject
Richard Porter
can't change CDs except by partially dismantling the computer to get
at the innards. It appears to be trying to push the tray out, but then
gives up. There is a paper clip size hole but I can't make it eject
the disc. Anyone else had this problem?
--
Richard Porter
rich@ / www. richardporter.me.uk
"You can't have Windows without pains."
David Holden
On 23-Jun-2008, Richard Porter <dontu...@address.uk.invalid> wrote:
> I have a Ricoh MP7200A in a RiscPC. Recently it stopped ejecting and I
> can't change CDs except by partially dismantling the computer to get
> at the innards. It appears to be trying to push the tray out, but then
> gives up. There is a paper clip size hole but I can't make it eject
> the disc. Anyone else had this problem?
Like a lot of CD drives I think the tray servo motor dives through a small
rubber belt. These either stretch or lose their elasticity with age. I've
often managed to replace them with a small rubber band but it's a fiddly
process. However, since drives are now so cheap it might not be worth the
trouble.
--
David Holden - APDL - <http://www.apdl.co.uk>
Chris Shepheard
"David Holden" <Spa...@apdl.co.uk> wrote:
Yes we had a DVD drive (Tesco about 18 months old) at work that
developed this fault (it made an awful noise when you tried to eject
the disc).
I replaced it with a new one (£19!) and then thought I'd get the disc
out by dismantling the machine. As you say the belt had broken and
Tesco couldn't supply a replacement (and their manufacturer hasn't
replied to the email I sent about a month ago either!)
I tried the rubber band and an 'O' ring but couldn't get the tension
right. In the end I super-glued the original and it worked fine. Don't
know how long before the next bit of perished rubber gives up the
ghost and it might end up with a belt of super-glue!
All the belts I could find on the web were (just) the wrong size.
Chris
--
Chris Shepheard writing as himself
chris.s...@chrispics.co.uk
from far west Surrey www.chrispics.co.uk
Steffen Huber
> In article <6cad2gF...@mid.individual.net>,
> David Holden <Spa...@apdl.co.uk> wrote:
>> However, since drives are now so cheap it might not be worth the
>> trouble.
>
> replaced by DVD drives.
So buy a DVD drive which will read your CDs just fine.
Or better still, buy a DVD writer and CDVDBurn ;-)
Steffen
--
Steffen Huber
hubersn Software - http://www.hubersn-software.com/
Richard Porter
write:
> In article <095921b44f.ch...@shepheard.plus.com>,
> Chris Shepheard <chris.s...@chrispics.co.uk> wrote:
>> All the belts I could find on the web were (just) the wrong size.
> CPC do a lot of standard drive belts. When repairing a cassette recorder,
> because of stretch and deterioration, it was impossible to know the
> correct size so I ordered the length I thought and one each side.
Thanks for all the comments. I use the CD-R drive mainly for audio CDs
but at the moment it's got a bootable CD in just in case I have a hard
disc fault. I'm backing up to a Mac which itself is backed up to an
external hard drive by time machine.
A DVD burner is a possibility, but would it be just as slow at burning
CDs?
Chris Evans
<URL:mailto:Spa...@argonet.co.uk> wrote:
> In article <6cbtl0F...@mid.individual.net>,> Well, in my case, a DVD burner etc would be pointless as I only have a RPC
> and DVD burning is really beyond the poor thing.
It shouldn't be, a DVD Burner will burn CD and DVD ROMs are treated just
like larger capacity CDs.
Some cutomers have thought that it was for burning Moview DVDs only, it
isn't in fact it can't burn Moview DVDs as they are very different format to
DVD ROM
> I do my backups to CD or
> to another machine across the network. I have the last version of CDBurn.
>
> There is currently a discussion about some aspects of producing audio CDs
> elsewhere.
>
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!
Steffen Huber
> In article <6cbtl0F...@mid.individual.net>,
> Steffen Huber <sp...@huber-net.de> wrote:
>
> and DVD burning is really beyond the poor thing.
I would recommend to have a look at the virtues of DVD-RAM as a backup
medium. While the RPC might be slow when creating the data for a full
DVD, and also slow when writing the DVD-RAM, it is surely better to
write a few DVDs instead of splitting your backup over many CDs?
Depends on the size of your backups of course.
Anyway, since you can use any DVD writer as a CD writer, and seeing
that plain CD writers are difficult to buy nowadays, I guess that
some day you'll just give in and supply your RPC with a DVD writer.
They are incredibly cheap at the moment - 20 EUR for a brand new
LG drive.
> I do my backups to CD or
> to another machine across the network. I have the last version of CDBurn.
Ah, so upgrading to CDVDBurn would be cheap! ;-)
> There is currently a discussion about some aspects of producing audio CDs
> elsewhere.
Haven't seen it yet...but anyway, it reminds me of my rather long
list of things to do wrt CDVDBurn's audio capabilities...
druck
> Stuart wrote:
>> In article <6cbtl0F...@mid.individual.net>,
>> Steffen Huber <sp...@huber-net.de> wrote:
>>> Or better still, buy a DVD writer and CDVDBurn
>>
>> Well, in my case, a DVD burner etc would be pointless as I only have a RPC
>> and DVD burning is really beyond the poor thing.
> I would recommend to have a look at the virtues of DVD-RAM as a backup
> medium. While the RPC might be slow when creating the data for a full
> DVD, and also slow when writing the DVD-RAM, it is surely better to
> write a few DVDs instead of splitting your backup over many CDs?
I'd say any backup regime which involves the very slow writing of
multiple optical discs, is going to get done once in a blue moon if
that. Even if we went to BluRay, most of us would need more thaan one,
and I suspect it would take a fortnight to fill it.
The only useful backup, is a regular backup, and with RISC OS that
means a hard disc caddy. Using !DirSync to just copy the changes, it
can performed in a sensible timescale while the meachine is in use.
The quicker and easier the process, the more likely it is you'll do
it.
---druck
--
The ARM Club Free Software - http://www.armclub.org.uk/free/
The 32bit Conversions Page - http://www.quantumsoft.co.uk/druck/
David Holden
On 27-Jun-2008, druck <ne...@druck.freeuk.com> wrote:
> I'd say any backup regime which involves the very slow writing of
> multiple optical discs, is going to get done once in a blue moon if
> that. Even if we went to BluRay, most of us would need more thaan one,
> and I suspect it would take a fortnight to fill it.
>
> The only useful backup, is a regular backup, and with RISC OS that
> means a hard disc caddy. Using !DirSync to just copy the changes, it
> can performed in a sensible timescale while the meachine is in use.
> The quicker and easier the process, the more likely it is you'll do
> it.
Hear hear. CDs and DVDs are great for archiving but useless for regular
backing up. By far the best option is a hard drive in a caddy and it's also
transportable between machines so you can back up more than one computer to
a single drive. Also if you 'mirror' your main hard drive then if it does
fail you can just remove the HD from the caddy and install it in the
computer - total down time a few minutes.
This was the philosophy behind our DataSafe but a caddy drive is much
faster.
Dave Symes
David Holden <Spa...@apdl.co.uk> wrote:
'Xcuse me Mr H., I have a question. (I'm serious)
"...it's also transportable between machines..."
Erm! So I can backup my RO hardrive, then when this old, old SARPC dies I
can take the caddy mounted ADFS backup drive, connect it to my Windows
Vista Laptop, and read it successfully?
No!
Of course by that I mean VRPC-SA
Which can read FAT formatted Pen drives inserted in a USP port, so I guess
the question is, could VRPC also read an ADFS hardrive connected to the
Laptops USB port?
Cheers
Dave S
--
Chris Evans
<URL:mailto:Spa...@argonet.co.uk> wrote:
> In article <6chfboF...@mid.individual.net>,> How much?
From Full CDBurn 27 GBP
http://www.cjemicros.co.uk/micros/individual/prodpages/HUB-CDVDBRNUG.shtml
upgrade also available from CDBurn Lite
http://www.cjemicros.co.uk/micros/individual/prodpages/HUB-CDVDBRNUGL.shtml
Both in stock!
We also have compatible DVDRW drives.
Steffen Huber
> In article <6chfboF...@mid.individual.net>,> How much?
25 UKP from
http://www.hubersn-software.com/buy.html
John Cartmell
It would be interesting to know the price of those. Searching for DVD R/W
drives for a Mac has so far identified the cheapest at £129. One at £30 was
offered but the manufacturer (Pioneer) denies that it works on a Mac!
--
John Cartmell jo...@finnybank.com 0845 006 8822 or 0161 969 9820
Qercus magazine FAX +44 (0)8700-519-527 www.qercus.com
Qercus - the best guide to RISC OS computing
Rob Kendrick
> In article <ant27130...@client.cjemicros.co.uk>,
> Chris Evans <ch...@cjemicros.co.uk> wrote:
>> We also have compatible DVDRW drives.
>
> It would be interesting to know the price of those. Searching for DVD
> R/W drives for a Mac has so far identified the cheapest at £129. One at
> £30 was offered but the manufacturer (Pioneer) denies that it works on a
> Mac!
Depends what sort of Mac you've got. If you've got a Mac Pro, and any
old writer drive you pick up for 20 or 30 quid doesn't work, it's time to
get angry at Apple, not the drive manufacturers.
If you have an "all in one" Mac, then you got what you deserved when you
bought such a machine!
B.
John Cartmell
> > In article <ant27130...@client.cjemicros.co.uk>,
> > Chris Evans <ch...@cjemicros.co.uk> wrote:
> >> We also have compatible DVDRW drives.
> >
> > It would be interesting to know the price of those. Searching for DVD
> > R/W drives for a Mac has so far identified the cheapest at £129. One at
> > £30 was offered but the manufacturer (Pioneer) denies that it works on a
> > Mac!
> Depends what sort of Mac you've got. If you've got a Mac Pro, and any
> old writer drive you pick up for 20 or 30 quid doesn't work, it's time to
> get angry at Apple, not the drive manufacturers.
There seems to be a great deal of defensiveness. I've found a few references
to "this one works with no problem" but they all seem to be for drives that
are now obsolete. Mac retailers offer the Apple SuperDrive that appears to be
of lower spec than a £20 drive, and general retailers simply say that they
sell Windows drives only. Whilst the SuperDrive is guaranteed to work you
could try half a dozen or more 'standard' drives before that guarantee showed
its worth.
We might complain about the cost of RISC OS stuff but that's nothing compared
to what could be!
Rob Kendrick
> In article <4u89k.50657$aE7....@newsfe16.ams2>,
> Rob Kendrick <nn...@rjek.com> wrote:
>> On Fri, 27 Jun 2008 16:31:54 +0100, John Cartmell wrote:
>
>> > In article <ant27130...@client.cjemicros.co.uk>,
>> > Chris Evans <ch...@cjemicros.co.uk> wrote:
>> >> We also have compatible DVDRW drives.
>> >
>> > It would be interesting to know the price of those. Searching for DVD
>> > R/W drives for a Mac has so far identified the cheapest at £129. One
>> > at £30 was offered but the manufacturer (Pioneer) denies that it
>> > works on a Mac!
>
>> Depends what sort of Mac you've got. If you've got a Mac Pro, and any
>> old writer drive you pick up for 20 or 30 quid doesn't work, it's time
>> to get angry at Apple, not the drive manufacturers.
>
> There seems to be a great deal of defensiveness. I've found a few
> references to "this one works with no problem" but they all seem to be
> for drives that are now obsolete. Mac retailers offer the Apple
> SuperDrive that appears to be of lower spec than a £20 drive, and
> general retailers simply say that they sell Windows drives only. Whilst
> the SuperDrive is guaranteed to work you could try half a dozen or more
> 'standard' drives before that guarantee showed its worth.
Well, indeed. These inflated prices often have this property - the RISC
OS world is not immune to them, either. However, Apple do take this to a
whole new level. (It used to cost you an extra 30 quid to have your
Macbook in black instead of tacky white, and their bundled-memory prices
are pure fantasy.)
However, if your machine has a standard 5.25" drive bay, purchasing a
suitably-interfaced drive (ie, PATA or SATA, I don't know which Mac Pros
use) should work. If it doesn't, it's Apple being bloody-minded. And as
long as you buy it mail order rather than from a shop physically, you can
of course return the drive for a full refund under the distance selling
laws.
B.
Grahame Parish
Chris Evans <ch...@cjemicros.co.uk> wrote:
> In article <4fb57de5...@argonet.co.uk>, Stuart
> <URL:mailto:Spa...@argonet.co.uk> wrote:
>> In article <6chfboF...@mid.individual.net>,
>> Steffen Huber <sp...@huber-net.de> wrote:
>>> Ah, so upgrading to CDVDBurn would be cheap! ;-)
>>
>> How much?
> From Full CDBurn 27 GBP
> http://www.cjemicros.co.uk/micros/individual/prodpages/HUB-CDVDBRNUG.shtml
> upgrade also available from CDBurn Lite
> http://www.cjemicros.co.uk/micros/individual/prodpages/HUB-CDVDBRNUGL.shtml
> Both in stock!
> We also have compatible DVDRW drives.
> Chris Evans
Will it work with an LG GSA-4120B drive that I have spare here? If so
I might take you up on a copy.
--
Grahame
maillistDOTparishATmillersHYPHENwayDOTnet
druck
> In article <6cjf6qF...@mid.individual.net>,
> David Holden <Spa...@apdl.co.uk> wrote:
>> By far the best option is a hard drive in a caddy and it's
>> also transportable between machines so you can back up more than one
>> computer to a single drive. Also if you 'mirror' your main hard drive
>> then if it does fail you can just remove the HD from the caddy and
>> install it in the computer - total down time a few minutes.
>> This was the philosophy behind our DataSafe but a caddy drive is much
>> faster.
> 'Xcuse me Mr H., I have a question. (I'm serious)
> "...it's also transportable between machines..."
> Erm! So I can backup my RO hardrive, then when this old, old SARPC dies I
> can take the caddy mounted ADFS backup drive, connect it to my Windows
> Vista Laptop, and read it successfully?
> No!
Who mentioned Windows? This is a RISC OS newsgroup, so when people
mention multiple computers, the first assumption should that they are
RISC OS ones.
When I bought my system I wanted a cradle and two caddies + drives,
but I was given two cradles and caddies. So I installed on in the
Iyonix and one in the Risc PC, and they work excellently in each. If I
want bulk copy a few months of data between machines, swapping over
their compatible caddie drives is far quicker than copying via the
network.
> Of course by that I mean VRPC-SA Which can read FAT formatted Pen
> drives inserted in a USP port, so I guess the question is, could VRPC
> also read an ADFS hardrive connected to the Laptops USB port?
In theory, VRPC would need the necessary Windows driver.
Dave Symes
[Snip]
> > 'Xcuse me Mr H., I have a question. (I'm serious)
> > "...it's also transportable between machines..."
> > Erm! So I can backup my RO hardrive, then when this old, old SARPC
> > dies I can take the caddy mounted ADFS backup drive, connect it to my
> > Windows Vista Laptop, and read it successfully? No!
> Who mentioned Windows? This is a RISC OS newsgroup, so when people
> mention multiple computers, the first assumption should that they are
> RISC OS ones.
Me, me, me. I did, I mentioned Windows, because I think it's a legit
mention... VRPC is a branch of the RISC OS family.
An increasing number of folks are sensing the only way to stay with RO is
to have a copy of VRPC on a PC.
I have VRPC SA on my MS-Win Laptop and sync important stuff using
!DirSync, but in the context of Mr H's note, ("...it's also transportable
between machines...") and the age of my RO machine I consider it a useful
question to ask.
> When I bought my system I wanted a cradle and two caddies + drives,
> but I was given two cradles and caddies. So I installed on in the
> Iyonix and one in the Risc PC, and they work excellently in each. If I
> want bulk copy a few months of data between machines, swapping over
> their compatible caddie drives is far quicker than copying via the
> network.
> > Of course by that I mean VRPC-SA Which can read FAT formatted Pen
> > drives inserted in a USP port, so I guess the question is, could VRPC
> > also read an ADFS hardrive connected to the Laptops USB port?
> In theory, VRPC would need the necessary Windows driver.
So it seems the answer is NO!
Thanks
Dave S
--
Tim Powys-Lybbe
> An increasing number of folks are sensing the only way to stay with RO is
> to have a copy of VRPC on a PC.
Or Mac.
--
Tim Powys-Lybbe t...@powys.org
For a miscellany of bygones: http://powys.org/
Steffen Huber
> Will it work with an LG GSA-4120B drive that I have spare here? If so
> I might take you up on a copy.
There are still problems with LG drives that I am tackling
right now (due to the Blu-Ray writer being an LG).
Working right now with a released version of CDVDBurn is
DVD+RW and DVD-RAM. DVD-RW works sometimes, DVD+R seldomly...
Getting LGs to work was never a priority, since they haven't
worked on the IYONIX as a DVD reader and have also various
problems with other CDFSSoft* drivers.
I now have a slightly-patched CDFSSoftATAPI for the IYONIX
(thanks to RO Open!) which allows the LGs to work, but this
is not in a releasable state yet. Testers are welcome of
course ;-)
Grahame Parish
Steffen Huber <sp...@huber-net.de> wrote:
> Grahame Parish wrote:
>> Will it work with an LG GSA-4120B drive that I have spare here? If so
>> I might take you up on a copy.
> There are still problems with LG drives that I am tackling
> right now (due to the Blu-Ray writer being an LG).
I've got one of those in my business PC (GGW-H20L - which can be moved
for testing if necessary).
> Working right now with a released version of CDVDBurn is
> DVD+RW and DVD-RAM. DVD-RW works sometimes, DVD+R seldomly...
> Getting LGs to work was never a priority, since they haven't
> worked on the IYONIX as a DVD reader and have also various
> problems with other CDFSSoft* drivers.
> I now have a slightly-patched CDFSSoftATAPI for the IYONIX
> (thanks to RO Open!) which allows the LGs to work, but this
> is not in a releasable state yet. Testers are welcome of
> course ;-)
Let me know and I'll install the GSA-4120B in the Iyonix for testing
if required.
--
Grahame
maillistDOTparishATmillersHYPHENwayDOTnet
Dave Higton
Dave Symes <da...@triffid.co.uk> wrote:
> 'Xcuse me Mr H., I have a question. (I'm serious)
>
> "...it's also transportable between machines..."
>
> Erm! So I can backup my RO hardrive, then when this old, old SARPC dies I
> can take the caddy mounted ADFS backup drive, connect it to my Windows
> Vista Laptop, and read it successfully?
> No!
That would be because Windows is the least compatible OS on the
planet. It's only ever compatible with a small subset of itself.
Dave
Greg
daveh...@dsl.pipex.com says...
'Windows' is an OS.
Why would it need to be compatible with anything? Compatability is work
of applications.
--
Greg Harris (Norwich)
Dave Symes
> Dave
Well you are another Mr H and you've snipped the real/serious part of the
posting relating to VRPC and left in the jokey intro.
Do you actually know the answer to the real question?
Dave S
--
Ray Dawson
And when has Windows ever been able to read a RISC OS drive? And likewise,
when has RISC OS ever been able to read a Windows drive?
Neither have ever been compatible with each other.
Cheers,
Ray D
Dave Higton
Dave Symes <da...@triffid.co.uk> wrote:
I don't /know/. I /suppose/ the answer is that VRPC can't read an
ADFS hard drive successfully /because/ Windows (Vista or any other
version) can't read the hard drive, and an application such as VRPC
can't bypass the OS to read the drive itself. If what I suppose is
true, the authors of VRPC are stymied by Windows's lack of
compatibility and lack of hooks or permissions to provide
compatibility.
Dave
Dave Higton
Greg <gr...@nospam.demon.co.uk> wrote:
The context is reading hard disc drives. That's the work of OSs.
If the OS can't or won't read the HDD, apps can't read the files.
Dave
Dave Symes
Dave Higton <daveh...@dsl.pipex.com> wrote:
[Snip]
> I don't /know/. I /suppose/ the answer is that VRPC can't read an
> ADFS hard drive successfully /because/ Windows (Vista or any other
> version) can't read the hard drive, and an application such as VRPC
> can't bypass the OS to read the drive itself. If what I suppose is
> true, the authors of VRPC are stymied by Windows's lack of
> compatibility and lack of hooks or permissions to provide
> compatibility.
> Dave
Thanks for the info Dave.
I've started a new thread "HD transportability" about this business as I
feel it's of interest to all RISC OS users with dual OS systems...
Which-ever they might be.
Dave S
--
Dave Symes
Dave Higton <daveh...@dsl.pipex.com> wrote:
> Dave
I've started a new thread about this business as I feel it's of interest
to all RISC OS users with dual OS systems... Which-ever they might be.
As it seems an ADFS/IDEFS Harddisk is not transportable to the Win side,
next thoughts are:
IIRC. The USB systems used on RO cannot recognise/Read/Write an attached
hardrive (FAT or other) ?
If that is so, would it be possible for the vendors of RO USB to make it
possible to recognise/Read/Write an attached USB HardDisk?
Dave S
--
Ray Dawson
> > > That would be because Windows is the least compatible OS on the
> > > planet. It's only ever compatible with a small subset of itself.
> >
> > 'Windows' is an OS. Why would it need to be compatible with anything?
> > Compatability is work of applications.
>
> The context is reading hard disc drives. That's the work of OSs.
> If the OS can't or won't read the HDD, apps can't read the files.
I don't think that is correct.
I have a PVR which uses its own strange hard disc format (a Topfield).
Connected to my Windows PC the hard drive is recognised, but not read or
displayed in the filer.
If I run a specially written bit of software, the drive and files can be
accessed, copied etc. Although the OS can't read the drive, an application
can.
Couldn't the same thing be done for a RISC OS hard drive?
Cheers,
Ray D
Grahame Parish
Dave Symes <da...@triffid.co.uk> wrote:
>> Dave
My Iyonix will read/write to a USB connect hard drive (or stick) that
is formatted as FAT as long as it is less than 2GB capacity. ROFS
will (apparently, as I haven't used it) /read/ drives larger than
this, but I don't know what the upper limit is. There may be a
limited subset of FAT (FAT16, but maybe not FAT32 and some
non-standard variants) that can be accessed this way, and definitely
not, as far as I am aware, NTFS.
--
Grahame
maillistDOTparishATmillersHYPHENwayDOTnet
Steffen Huber
> And when has Windows ever been able to read a RISC OS drive? And likewise,
> when has RISC OS ever been able to read a Windows drive?
>
> Neither have ever been compatible with each other.
RISC OS 3.1 and later have always been able to read a certain
subset of Windows drives. In some combinations, a small
"connector" was needed (i.e. DOSMount or PCDisk), but those
were often provided by e.g. the SCSI podule, so it "just
worked" for most users.
I used this extensively in the 90s when networking was
slow and/or expensive.
Nowadays, things are a bit more complicated (e.g. with
NTFS, disc sizes larger than the ImageFS/Fileswitch file
size limit) when thinking about direct drive access, but
thanks to NAS technology, it is easier to actually achieve
the end result.
druck
> And when has Windows ever been able to read a RISC OS drive?
Only via the network.
> And likewise, when has RISC OS ever been able to read a Windows drive?
FAT 12, 16 and FAT32 drives (up to 2GB) are readable with DOSFS and
Win95FS. I don't know of any offically released NTFS tools though.
> Neither have ever been compatible with each other.
Never let facts get in the way of a good argument.
druck
> I don't /know/. I /suppose/ the answer is that VRPC can't read an
> ADFS hard drive successfully /because/ Windows (Vista or any other
> version) can't read the hard drive, and an application such as VRPC
> can't bypass the OS to read the drive itself.
It could, but it doesn't. As I said previously, it could be done with
a suitable driver, but there isn't likely to be sufficient demand for
VA to do this.
> If what I suppose is true, the authors of VRPC are stymied by
> Windows's lack of compatibility and lack of hooks or permissions to
> provide compatibility.
Windows will allow you to do it, but it isn't as straightforward as
the equivelent image filing system code used to implement foreign on
RISC OS.
Rob Kendrick
>> If what I suppose is true, the authors of VRPC are stymied by Windows's
>> lack of compatibility and lack of hooks or permissions to provide
>> compatibility.
>
> Windows will allow you to do it, but it isn't as straightforward as the
> equivelent image filing system code used to implement foreign on RISC
> OS.
Surely you just open the partition as any sector editor would? I'm sure
there's plenty of open-source code out there to crib a solution from.
B.
druck
You've got a funny idea of what a filing system is.
Rob Kendrick
> On 29 Jun 2008 Rob Kendrick <nn...@rjek.com> wrote:
>
>> On Sun, 29 Jun 2008 16:20:52 +0100, druck wrote:
>
>>>> If what I suppose is true, the authors of VRPC are stymied by
>>>> Windows's lack of compatibility and lack of hooks or permissions to
>>>> provide compatibility.
>>>
>>> Windows will allow you to do it, but it isn't as straightforward as
>>> the equivelent image filing system code used to implement foreign on
>>> RISC OS.
>
>> Surely you just open the partition as any sector editor would? I'm
>> sure there's plenty of open-source code out there to crib a solution
>> from.
>
> You've got a funny idea of what a filing system is.
Given the mention of VA, I was assuming access to such hard discs would
be done via it. With block access to the partition, VA could use it as
the basis of emulation for hard drives, and thus have RISC OS handle it.
(ie, rather than having a big fat file on the Windows side that is
emulated as a hard disc, have it work on a real device).
B.
Greg
> In message <MPG.22d0a2fa6...@news.demon.co.uk>
> Greg <gr...@nospam.demon.co.uk> wrote:
>
> > In article <c870a9b64f...@dsl.pipex.com>, daveh...@dsl.pipex.com
> > says...
> > > In message <4fb5e5e...@triffid.co.uk>
> > > Dave Symes <da...@triffid.co.uk> wrote:
> > >
> > > > 'Xcuse me Mr H., I have a question. (I'm serious)
> > > >
> > > > "...it's also transportable between machines..."
> > > >
> > > > Erm! So I can backup my RO hardrive, then when this old, old SARPC dies
> > > > I can take the caddy mounted ADFS backup drive, connect it to my
> > > > Windows Vista Laptop, and read it successfully? No!
> > >
> > > That would be because Windows is the least compatible OS on the planet.
> > > It's only ever compatible with a small subset of itself.
> >
> > 'Windows' is an OS. Why would it need to be compatible with anything?
> > Compatability is work of applications.
>
> The context is reading hard disc drives. That's the work of OSs.
> If the OS can't or won't read the HDD, apps can't read the files.
And Windows can read FAT and NTFS drives very well with the application
built into it, explorer.exe.
With other suitable applications it can read many more formats including
ADFS/IDEFS if somebody writes the app and driver. As Ray mentions
further down, I also use a java app to read the HD in my PVR (JAFusion).
--
Greg Harris (Norwich)
Dave Higton
> I've started a new thread about this business as I feel it's of interest
> to all RISC OS users with dual OS systems... Which-ever they might be.
>
> As it seems an ADFS/IDEFS Harddisk is not transportable to the Win side,
> next thoughts are:
>
> IIRC. The USB systems used on RO cannot recognise/Read/Write an attached
> hardrive (FAT or other) ?
They have (always?) been able to access FAT-formatted drives up to
2 GB.
My !ROFS application allows read-only access to FAT16 and FAT32
formatted drives on an Iyonix, larger than 2 GB. Although I
haven't done extensive testing, I'm not aware of any size limit
imposed by !ROFS smaller than the limits of the FAT16 and FAT32
formats. Clearly the files dragged out of !ROFS to RISC OS
could not be greater than 2 GB.
I can see ways in which !ROFS could be extended:
a) to permit write as well as read access;
b) to work with the Simtec stack;
c) to work with devices with block sizes over 1024 bytes[1].
It's "just" a case of my amassing sufficient motivation to do
the work - or someone else, given that !ROFS is available in
source form.
> If that is so, would it be possible for the vendors of RO USB to make it
> possible to recognise/Read/Write an attached USB HardDisk?
Yes. It already does, up to 2 GB. It could certainly be
extended to read all FAT16 and FAT32 discs of any size. It
could also in principle read and write NTFS and ext2/ext3/ext4
formatted discs. However, bear in mind that it's a fair
amount of work to extend RISC OS's capability like that.
You may find it preferable, however, to connect a large USB
hard drive to a NAS adaptor (one example being the Linksys
NSLU2) so that it's accessible to all devices on your network.
That's the way I access my 320 GB USB hard drive from RISC OS,
Linux and Windows.
Dave
[1] There are a few devices that are like this. I have been
lent a USB stick, and I have a Creative Zen Stone 1 GB MP3
player, that are. If you've never seen the error "Bad block
size - must be 256/512/1024" or similar, don't worry about
it.
Ray Dawson
> On 28 Jun 2008 Ray Dawson <r...@magray.freeserve.co.uk> wrote:
> > And when has Windows ever been able to read a RISC OS drive?
>
> Only via the network.
>
> > And likewise, when has RISC OS ever been able to read a Windows drive?
>
> FAT 12, 16 and FAT32 drives (up to 2GB) are readable with DOSFS and
> Win95FS. I don't know of any offically released NTFS tools though.
The OP was talking about moving a hard drive between operating systems -
not reading it over a network or as a flash card.
AFAIK you cannot stick a Windows hard drive into a RISC OS machine and
read it directly = and vive versa. You can read a DOS floppy on RISC OS,
but seemingly not a hard drive.
Cheers,
Ray D
David Holden
On 30-Jun-2008, Ray Dawson <r...@magray.freeserve.co.uk> wrote:
> The OP was talking about moving a hard drive between operating systems -
> not reading it over a network or as a flash card.
>
> AFAIK you cannot stick a Windows hard drive into a RISC OS machine and
> read it directly = and vive versa. You can read a DOS floppy on RISC OS,
> but seemingly not a hard drive.
Not strictly true. The problem is the way DOSFS works which limits it to
2GB. (I know ROFS extends this but only for reading USB drives on the
Iyonix.). If your hard drive is <2GB then it can be read on an Acorn
machine, but that's not a lot of use in the 'real world'.
For example, I can read and write to a DOS formatted 1GB Syquest SparQ drive
(effectively a hard drive) without problems on my RiscPC.
--
David Holden - APDL - <http://www.apdl.co.uk>
Jess
Dave Higton <daveh...@dsl.pipex.com> wrote:
> My !ROFS application allows read-only access to FAT16 and FAT32
> formatted drives on an Iyonix, larger than 2 GB. Although I
> haven't done extensive testing, I'm not aware of any size limit
> imposed by !ROFS smaller than the limits of the FAT16 and FAT32
> formats. Clearly the files dragged out of !ROFS to RISC OS
> could not be greater than 2 GB.
What happens with larger files? Do they fail immediately or do you get
the first 2GB?
Would it be possible to split them in the a way compatible with what
CDVDBurn does?
(eg, for when there is a 3GB iso on a drive)
--
Jess Iyonix
Hotmail is my spam trap use this for reply:
mailto:nos...@jess.itworkshop-nexus.net or
http://jess.itworkshop-nexus.net
davehigton
> In message <e84d2eb74f.davehig...@dsl.pipex.com>
> Dave Higton <davehig...@dsl.pipex.com> wrote:
>
> > My !ROFS application allows read-only access to FAT16 and FAT32
> > formatted drives on an Iyonix, larger than 2 GB. Although I
> > haven't done extensive testing, I'm not aware of any size limit
> > imposed by !ROFS smaller than the limits of the FAT16 and FAT32
> > formats. Clearly the files dragged out of !ROFS to RISC OS
> > could not be greater than 2 GB.
>
> What happens with larger files? Do they fail immediately or do you get
> the first 2GB?
I don't know. I've never had access to a larger file to try.
I can't remember right now whether FAT32 permits files larger than
4 GB.
> Would it be possible to split them in the a way compatible with what
> CDVDBurn does?
>
> (eg, for when there is a 3GB iso on a drive)
In principle, yes. !ROFS just looks at sectors and clusters, so
it could deliver a file as large as the entire drive. Therefore
it could also split it up as required.
Dave
Steffen Huber
> I can't remember right now whether FAT32 permits files larger than
> 4 GB.
FAT32 as used in Windows ME allowed 4 GB file size instead of 2 GB like
previous versions, but that is the limit.
Rob Kendrick
> davehigton wrote:
>> I can't remember right now whether FAT32 permits files larger than 4
>> GB.
>
> FAT32 as used in Windows ME allowed 4 GB file size instead of 2 GB like
> previous versions, but that is the limit.
As a pedantic aside, FAT32 is available in Windows 95 OSR2 onwards, and
the maximum file size is 4GB - 1 byte. :)
B.
davehigton
> davehigton wrote:
> > I can't remember right now whether FAT32 permits files larger than
> > 4 GB.
>
> FAT32 as used in Windows ME allowed 4 GB file size instead of 2 GB like
> previous versions, but that is the limit.
Thanks, Steffen, that's what I thought.
Anyone can chain all the clusters together and get a file as big as
the data space on the drive, but the length field of the directory
entry is only 32 bits, so that defines the limit.
Dave
Jess (Imhotep)
> On 30 Jun, 08:13, Jess <phantasm...@hotmail.com> wrote:
> > Would it be possible to split them in the a way compatible with what
> > CDVDBurn does?
>
> > (eg, for when there is a 3GB iso on a drive)
>
> it could deliver a file as large as the entire drive. Therefore
> it could also split it up as required.
It would be good if all the programs that need bigger than 2GB files
could use the same splitting scheme as a stopgap until RISC OS can
support big files itself.
--
Jess
Peter Naulls
No, once again, we need to insist upon avoidance of hacks, particularly
in this situation.
Dave Higton
"Jess (Imhotep)" <jessha...@googlemail.com> wrote:
What would you do with a file that had been split? (Except the
rather special case of an ISO image for a DVD.)
Dave
druck
> druck <ne...@druck.freeuk.com> wrote:
>> On 28 Jun 2008 Ray Dawson <r...@magray.freeserve.co.uk> wrote:
>>> And when has Windows ever been able to read a RISC OS drive?
>>
>> FAT 12, 16 and FAT32 drives (up to 2GB) are readable with DOSFS and
>> Win95FS. I don't know of any offically released NTFS tools though.
> The OP was talking about moving a hard drive between operating systems -
> not reading it over a network or as a flash card.
> AFAIK you cannot stick a Windows hard drive into a RISC OS machine and
> read it directly = and vive versa. You can read a DOS floppy on RISC OS,
> but seemingly not a hard drive.
You are wrong ray. Any filing system which offers issues the service
call for foriegn filing systems will work equally well with hard discs
as for removeable media, with the size caveat mentioned previously.
Back in the days of the PC Card we used to take 1G and 2G SCSI discs
straight out of Windows machines, and they could be accessed directly
by RISC OS via DOS FS. PC Card could use them either via RISC OS or
its own ASPI driver for better performance.
Steffen Huber
> Jess (Imhotep) wrote:
>> It would be good if all the programs that need bigger than 2GB files
>> could use the same splitting scheme as a stopgap until RISC OS can
>> support big files itself.
>
> No, once again, we need to insist upon avoidance of hacks, particularly
> in this situation.
That is certainly the case in an ideal world. However, I fear
that the number of people with both the necessary knowledge and
time to implement the proper solution approaches zero.
The quick hack done for CDVDBurn needs 5 minutes of programming
and can be done by any old application developer (like me).
Anyway, if someone wants to have a go at the proper solution
(extending or rewriting FileSwitch, providing a new FS running
on top of it), I would be prepared to donate a significant
amount of money.
David Holden
On 30-Jun-2008, druck <ne...@druck.freeuk.com> wrote:
> On 30 Jun 2008 Ray Dawson <r...@magray.freeserve.co.uk> wrote:
>
> > The OP was talking about moving a hard drive between operating systems -
> > not reading it over a network or as a flash card.
>
> > AFAIK you cannot stick a Windows hard drive into a RISC OS machine and
> > read it directly = and vive versa. You can read a DOS floppy on RISC OS,
> > but seemingly not a hard drive.
>
> You are wrong ray. Any filing system which offers issues the service
> call for foriegn filing systems will work equally well with hard discs
> as for removeable media, with the size caveat mentioned previously.
>
> Back in the days of the PC Card we used to take 1G and 2G SCSI discs
> straight out of Windows machines, and they could be accessed directly
> by RISC OS via DOS FS. PC Card could use them either via RISC OS or
> its own ASPI driver for better performance.
Still works. I can read and write perfectly to a 1GB DOS formatted Syquest
SparQ drive under RISC OS which although it has removable discs is,
effectively, a hard drive.
Tim Powys-Lybbe
So would I. A crate of champagne, even.
--
Tim Powys-Lybbe t...@powys.org
For a miscellany of bygones: http://powys.org/
Rob Kendrick
> Anyway, if someone wants to have a go at the proper solution (extending
> or rewriting FileSwitch, providing a new FS running on top of it), I
> would be prepared to donate a significant amount of money.
One of the issues I've spotted here is that it is difficult to replace
FileSwitch at runtime, given so much of the OS depends on it. It has to
be there at boot, which means any such developer needs the ability to
create working and usable ROM images to make the process less utterly
painful :-/
B.
Steffen Huber
This might be a problem when all is done (and we need a proper plan
for final deployment anyway - after all, we want the new
FileSwitch to be available for all RISC OS machines!), but surely
initial development would create a new "FileSwitch2" module with a
different SWI base, and a new FS running on top of it. This
could be easily connected via a low-level block driver to
e.g. an external USB drive (or even a set of files on the host
machine simulating a disc image).
Once all this and the test code (using the FileSwitch2 calls)
runs fine, I guess we have figured out a solution for the above
problem ;-)
Rob Kendrick
Yes, this would let you get the bulk of common functionality done and
tested. But FileSwitch does do a lot besides that's essential to the
operation of RISC OS that you really need it in from the start in order
to develop and test a replacement.
Perhaps a better option is to have an entirely new file system stack (the
right way around this time, please! :) that provides a compatibility
layer to old applications using vectors? This allows core functionality
that must exist to be handled by the existing FileSwitch, but actual data
file storage and retrieval to be handed by this new stack, with new and
sane API.
RISC OS's current file system stack, other than being a hideous hack, is
eye-wateringly complex. Just compare the number of system calls it
provides (ie, all the OS_FSControl, OS_GBPB, OS_BGet/BPut, etc etc etc) -
well into the hundreds. This rivals even Windows. (Comparitively, UNIX
traditionally has less than 50).
I'm interested in helping discuss and implement such a venture, but I
fear I do not have enough spare time to lead it.
B.
B.
John Tytgat
> RISC OS's current file system stack, other than being a hideous hack, is
> eye-wateringly complex.
Mmh, that does not really match with my experience.
> Just compare the number of system calls it
> provides (ie, all the OS_FSControl, OS_GBPB, OS_BGet/BPut, etc etc etc) -
> well into the hundreds. This rivals even Windows. (Comparitively, UNIX
> traditionally has less than 50).
Actually when you implement a RISC OS FS you don't have to implement all
those calls available to the user. A lot is done by FileSwitch (luckily
enough). The PRM contains a section what needs to be done.
John.
Rob Kendrick
>> Just compare the number of system calls it provides (ie, all the
>> OS_FSControl, OS_GBPB, OS_BGet/BPut, etc etc etc) - well into the
>> hundreds. This rivals even Windows. (Comparitively, UNIX
>> traditionally has less than 50).
>
> Actually when you implement a RISC OS FS you don't have to implement all
> those calls available to the user. A lot is done by FileSwitch (luckily
> enough). The PRM contains a section what needs to be done.
We're talking about replacing the VFS (ie, FileSwitch), not just writing
a new file system to plug into the existing FileSwitch.
B.
Dave Higton
John Tytgat <th...@is.invalid> wrote:
That's the way I have always understood it, too. I don't understand
why there is all this talk of replacements for FileSwitch or even
the entire filing system stack.
Dave
Peter Naulls
No? Can't you name a single issue with it? Obviously there's the
2GB issue, which I suspect calls for some very major work to address
or even a replacement.
Apart from that, the ridiculous duplication that occurs over all the
CDFS drivers, and SCSI drivers for that matter - all have their own
special way of handling ATAPI/SCSI commands.
And let's not forget HForm - a rather more simplistic problem, and
can be separated from this, but all in all a bit hopeless, running
into integer maximums in BASIC, and never mind that everyone rewrote
it for their own filesystem, instead of having a comprehensive
and robust single program to do it.
Let's not forget file locks (no, not the ADFS locks), full permissions,
and smooth integration of alternate filesystems - VFAT, ext2 alongside
Filecore.
I don't think I'm naming anything here which should be a surprise.
Dave Higton
Peter Naulls <pe...@chocky.org> wrote:
> Dave Higton wrote:
> > In message <g4do93$r49$1...@aioe.org>
> > John Tytgat <th...@is.invalid> wrote:
> >
> > > Rob Kendrick wrote:
> > > > RISC OS's current file system stack, other than being a hideous hack,
> > > > is eye-wateringly complex.
> > > Mmh, that does not really match with my experience.
> > >
> > > > Just compare the number of system calls it provides (ie, all the
> > > > OS_FSControl, OS_GBPB, OS_BGet/BPut, etc etc etc) - well into the
> > > > hundreds. This rivals even Windows. (Comparitively, UNIX
> > > > traditionally has less than 50).
> > > Actually when you implement a RISC OS FS you don't have to implement
> > > all those calls available to the user. A lot is done by FileSwitch
> > > (luckily enough). The PRM contains a section what needs to be done.
> >
> > That's the way I have always understood it, too. I don't understand why
> > there is all this talk of replacements for FileSwitch or even the entire
> > filing system stack.
>
> No? Can't you name a single issue with it? Obviously there's the 2GB
> issue, which I suspect calls for some very major work to address or even a
> replacement.
Although I've never tried it, I had always understood that a FS
implemented under FileSwitch would not necessarily suffer from
the 2 GB limitation. An image FS would, of course. Have I not
understood correctly?
> Apart from that, the ridiculous duplication that occurs over all the CDFS
> drivers, and SCSI drivers for that matter - all have their own special way
> of handling ATAPI/SCSI commands.
>
> And let's not forget HForm - a rather more simplistic problem, and can be
> separated from this, but all in all a bit hopeless, running into integer
> maximums in BASIC, and never mind that everyone rewrote it for their own
> filesystem, instead of having a comprehensive and robust single program to
> do it.
>
> Let's not forget file locks (no, not the ADFS locks), full permissions, and
> smooth integration of alternate filesystems - VFAT, ext2 alongside
> Filecore.
>
> I don't think I'm naming anything here which should be a surprise.
I agree that it could all do with an overhaul; what major software
couldn't? But I still don't see a convincing case for replacement.
Dave
John Williams (News)
I see all these names whom I know understand RISC OS at various high levels.
Whilst PN would like a 'proper' solution, and RJEK sees related areas which
need attention, could we address here the minimum effort required to remove
the 2GB image file limit which is preventing many areas of compatibility.
DH and SH have produced work-arounds permitting certain operations, but,
yes, these /are/ hacks. But useful ones extending the use of RISC OS.
Of course, the universal solution would be great - but what is the minimum
we need to cope with this problem for starters?
JT tends to work in the background, but I must acknowledge his contribution
as well.
As I say - all people who have demonstrated they know stuff. Can we have an
agreed way forward?
John
--
John Williams, Brittany, Northern France - no attachments to these addresses!
Non-RISC OS posters change user to johnrwilliams or put 'risc' in subject
for reliable contact! Who is John Williams? http://www.picindex.info/author/
Somewhere nice to stay in Brittany? http://petit.four.free.fr/visitors/locate
Peter Naulls
> I see all these names whom I know understand RISC OS at various high levels.
>
> Whilst PN would like a 'proper' solution, and RJEK sees related areas which
need attention, could we address here the minimum effort required to remove
the 2GB image file limit which is preventing many areas of compatibility.
DH and SH have produced work-arounds permitting certain operations, but,
yes, these /are/ hacks. But useful ones extending the use of RISC OS.
[snip]
No, this is not at all helpful. This is the point in the past at which
users have made it so difficult for developers by insisting on
short-term solutions - i.e. hacks, and pretending that they know
more about how to reach a solution than the developers do.
I think I can fairly say that no developer here has a complete
picture yet of what to do (although some might be pretty close); I've
not looked at much of the relevant code, but I've written on this
topic before, and can outline ways in which things really ought
to fit together the big picture.
What's "correct" and "proper" might be open to various opinions,
but I must insist that you and others try to not trivialise
this process. Just fixing part of the issue for the benefit
of one or two programs might give some short term joy, but it'll
soon make things harder for anything else. (There's plenty
of examples of this in RISC OS history)
The correct procedure at this point is simply more discussion about
perceived and demonstrated issues. Ultimately what's likely to
happen is that after such time is that one developer who has a real
interest in it will implement something based upon his priorities in a
hopefully extensible manner, and allow others to build on it.
This is going to take a long time, make no mistake.
druck
> Perhaps a better option is to have an entirely new file system stack (the
> right way around this time, please! :) that provides a compatibility
> layer to old applications using vectors? This allows core functionality
> that must exist to be handled by the existing FileSwitch, but actual data
> file storage and retrieval to be handed by this new stack, with new and
> sane API.
Yes, but thats a complete waste of time, what is going to use this new
API? All those thousands of RISC OS programs, which people will write
if only the 2GB file limit is lifted?
CDVDBurn is about the only RISC OS program that can do anything useful
with greater than 2GB files, we don't have anything else such as video
editors which work on files of that size.
Designing a whole new API and stack would a pointless exercise, all
thats needed is a couple of new OS_GBPBs to handle random access with
64bit file offset and return directory information with 64bit file
size.
Only if it is trivally easy to replace the existing call with the new
one does it stand any chance of being used. I certainly wouldn't
rewrite any of my code to use a whole new API on the off chance it
could ever do something useful with more than 2GB of data.
> RISC OS's current file system stack, other than being a hideous hack, is
> eye-wateringly complex. Just compare the number of system calls it
> provides (ie, all the OS_FSControl, OS_GBPB, OS_BGet/BPut, etc etc etc) -
> well into the hundreds. This rivals even Windows. (Comparitively, UNIX
> traditionally has less than 50).
I disagree about the complexity, but the main point is that is how it
is, and its too late in the day for this platform to throw it all away
and start again.
> I'm interested in helping discuss and implement such a venture, but I
> fear I do not have enough spare time to lead it.
With that in mind, lets not get in to architecturing a new towering
edifice stack and API, and forget that it will probably never be used.
We should be looking at the very least changes that allow us to take
advantage of a replacement to Filecore format, and to lift the 2GB
limit.
Rob Kendrick
> Although I've never tried it, I had always understood that a FS
> implemented under FileSwitch would not necessarily suffer from the 2 GB
> limitation. An image FS would, of course. Have I not understood
> correctly?
You have not understood correctly. FileSwitch, as it is, cannot provide
access to files more than 2GB large. It is a fundamental limitation of
its design, and its API. Image file systems suffer the 2GB limitation
because of this.
> I agree that it could all do with an overhaul; what major software
> couldn't? But I still don't see a convincing case for replacement.
Try comparing it to the offerings elsewhere, and you'll see it's in a
shocking state! The file system is one of the parts of RISC OS that's
firmly wedged in the past.
B.
Steffen Huber
achievable in a reasonable time frame. I'm using Peter's
points as a guiding line.
Peter Naulls wrote:
> Obviously there's the
> 2GB issue, which I suspect calls for some very major work to address
> or even a replacement.
I would propose doing just an extension for the few calls that
need to handle 64bit file lengths. We need to keep the old
feature set because so many things rely on it - I don't think
it would be sensible e.g. to try to port filecore to the extended
API. You could of course "fake" large files with multiple objecs,
but that sounds like one hack too much.
Software using the old API would only be able to see the first
2 GB of every large file, but that is not really a problem - most
software does not have a need for large file support. DOSFS
would be a likely first candidate to use the new API, the source
is already available from ROOL.
I think Alex Waugh's ideas are spot on for such a way forward:
http://www.riscosopen.org/wiki/documentation/pages/FilingSystemUpdate
I also agree with druck that at the moment, the only *real* usage
of a 64bit enabled FileSwitch would be lifting the 2 GB limit for
image fses. An over-ambitious "replace-the-whole-FS-stack" approach
is just not the right answer for such a comparatively small
"problem". IMHO of course.
> Apart from that, the ridiculous duplication that occurs over all the
> CDFS drivers, and SCSI drivers for that matter - all have their own
> special way of handling ATAPI/SCSI commands.
This would be easily solved by providing "block drivers" for the
hardware and implement generic drivers for the things needed (which
is basically only CDFS and CDVDBurn).
We already have most of the necessary framework in the form of the
SCSISwitcher. Implementing the IYONIX ATAPI system as a SCSISwitcher
module would be a first logical step.
> And let's not forget HForm - a rather more simplistic problem, and
> can be separated from this, but all in all a bit hopeless, running
> into integer maximums in BASIC, and never mind that everyone rewrote
> it for their own filesystem, instead of having a comprehensive
> and robust single program to do it.
I guess HForm is just to be seen as "legacy". Every FS that possibly
needs it already has a variant or three.
We just have to take care not to make the same mistake again...
> Let's not forget file locks (no, not the ADFS locks), full permissions,
> and smooth integration of alternate filesystems - VFAT, ext2 alongside
> Filecore.
Permissions is a difficult topic since there are so many
different solutions on other platforms.
"Smooth integration" - I have never seen the API that a Linux FS
must use to integrate itself into the system. It would be very
valuable to be able to easily reuse code from open source FSes,
but is this really realistic? I would be interested to hear
more details about this from someone who knows the FS situation
on Unix-like OSes.
Steffen Huber
> One of the issues I've spotted here is that it is difficult to replace
> FileSwitch at runtime, given so much of the OS depends on it.
There is an interesting technique mentioned in one of the docs
in the ROOL sources. See Sources\FileSys\FileSwitch\Doc\Log,
section "How to load a new FileSwitch module".
Peter Naulls
> "Smooth integration" - I have never seen the API that a Linux FS
> must use to integrate itself into the system. It would be very
> valuable to be able to easily reuse code from open source FSes,
> but is this really realistic? I would be interested to hear
> more details about this from someone who knows the FS situation
> on Unix-like OSes.
VFS is the system on Linux. It's pretty straightforward,
although it works in terms of inodes instead of files - in
fact the ADFS filesystem in Linux is nice example of a
simplistic file system. There's also FUSE (filesystems
in user space) in which it is easier to not to take out the
whole system with if you make a mistake, but not quite as
flexible.
Whether there's value in trying to make such things work
on RISC OS, I don't know - certainly making FUSE stuff
work I don't think would be out of the question - e.g,
you could "just" compile the NTFS handler, and then
you can magically read/write NTFS discs.
But what I really meant was a bit less specific - only
that we think in terms of file systems more general
than ADFS. IMO, the way things work with image
file systems is a bit odd (although very useful
back in the day with a PC card), since you have
this concept of the whole partition being an "image",
which isn't an unusable model, but different to
how everyone else does it.
Rob Kendrick
> Yes, but thats a complete waste of time, what is going to use this new
> API? All those thousands of RISC OS programs, which people will write if
> only the 2GB file limit is lifted?
The idea is that applications that want to process large files, use file
system transactions, make use of extended meta data, use online searches,
control partitioning/file system shrinking and growing etc etc use the
old API. Anything that doesn't care about any of that uses the old API
via the compatibility layer. You're going to have to change the API do
remove the 2GB limit /anyway/ - why not rationalise it and make it
simpler and more robust at the same time?
> CDVDBurn is about the only RISC OS program that can do anything useful
> with greater than 2GB files, we don't have anything else such as video
> editors which work on files of that size.
Anything that downloads files. Such as, say, DVD ISOs to burn with
CDVDBurn springs to mind.
> Designing a whole new API and stack would a pointless exercise, all
> thats needed is a couple of new OS_GBPBs to handle random access with
> 64bit file offset and return directory information with 64bit file size.
No, it wouldn't be a pointless exercise, because it would fix all the
other issues that myself and Peter have raised too - not just a fudge
around the 2GB issue.
> With that in mind, lets not get in to architecturing a new towering
> edifice stack and API,
Indeed not - let's not make the mistake that Acorn made and produce a
hideously designed hugely complicated mess.
B.
Theo Markettos
> You may find it preferable, however, to connect a large USB
> hard drive to a NAS adaptor (one example being the Linksys
> NSLU2) so that it's accessible to all devices on your network.
> That's the way I access my 320 GB USB hard drive from RISC OS,
> Linux and Windows.
A slightly perverse way of doing it, but to connect an ADFS HD to a Windows
machine you could do:
Get a NAS box that runs Linux
Pick a kernel that has the adfs.ko module compiled for it
Get a 5.25" IDE-USB case
Put a caddy frame inside the case and slot in the ADFS HD
Connect the case to the NAS by USB and the NAS to the network
Linux is quite happy at reading ADFS discs with the adfs.ko module, and this
way you make yourself a little Linux machine to serve the ADFS disc to
Windows.
Or you could just plug the drive into a Linux machine. RPCEmu should cope
with it just fine :)
Theo
Peter Naulls
In both of those cases - not quite - AFAIR, the ADFS stuff doesn't have
support for RISC OS filetypes (simply adding ,xxx to the end when
appropriate), so RPCEmu won't know what to do with the files. Years
ago I did a small patch to Linux ADFS to do exactly this, but it
got lost after its submission for mainstream inclusion.
Steffen Huber
> Steffen Huber wrote:
>
>> "Smooth integration" - I have never seen the API that a Linux FS
>> must use to integrate itself into the system. It would be very
>> valuable to be able to easily reuse code from open source FSes,
>> but is this really realistic? I would be interested to hear
>> more details about this from someone who knows the FS situation
>> on Unix-like OSes.
>
> VFS is the system on Linux. It's pretty straightforward,
> although it works in terms of inodes instead of files - in
> fact the ADFS filesystem in Linux is nice example of a
> simplistic file system. There's also FUSE (filesystems
> in user space) in which it is easier to not to take out the
> whole system with if you make a mistake, but not quite as
> flexible.
Thanks for that. I had a quick look at FUSE, its API and the
available FS modules for it.
I think FUSE and the FileSwitch API for a new FS are reasonably
close to be able to write an interface between the two - based
on my understanding after reading
http://www.ibm.com/developerworks/linux/library/l-fuse/
It would certainly be interesting to have FAT/NTFS/ZFS support
"for free". Didn't know about NTFS-3G - I always thought that
it was the lack of a good NTFS driver that was the reason for
all those NAS devices not touching NTFS.
Theo Markettos
> In both of those cases - not quite - AFAIR, the ADFS stuff doesn't have
> support for RISC OS filetypes (simply adding ,xxx to the end when
> appropriate), so RPCEmu won't know what to do with the files. Years
> ago I did a small patch to Linux ADFS to do exactly this, but it
> got lost after its submission for mainstream inclusion.
Yup, I did wonder about that. Any chance of you digging out the patch?
FWIW I think RPCEmu should cope if you give it the disc image as a file - it
should emulate it as an ADFS IDE drive. I tried it a while ago and ran into
some problems - I think Tom fixed them but I never got around to checking.
Meanwhile I don't know what happens if you provide the HD device
file direct to RPCEmu - ie tell RPCEmu its ADFS disc image is /dev/hdX.
There's an outside chance it might work.
Theo
Theo Markettos
> Thanks for that. I had a quick look at FUSE, its API and the
> available FS modules for it.
>
> I think FUSE and the FileSwitch API for a new FS are reasonably
> close to be able to write an interface between the two - based
> on my understanding after reading
> http://www.ibm.com/developerworks/linux/library/l-fuse/
You're right - after poking around the source of various FUSE modules it
does look plausible. Not quite trivially cross-compilable, but not far off.
There are a couple of pitfalls... those FUSE modules written in
perl/python/whatever probably wouldn't work. The simplest way would be just
to compile FUSE modules in C into RISC OS modules (ie running in supervisor
mode). You /could/ try to keep them in userspace with some kind of message
passing system, but I don't think it would work well.
There would also need to be some way to reliably deliver blocks to the
filesystem for it to interpret. I don't think the current mess of
ADFS_DiscOp, SCSI_DiscOp, SCSIFS_DiscOp, IDEFS_DiscOp, OS_GBPB etc etc is
something a FUSE module should have to worry about.
> It would certainly be interesting to have FAT/NTFS/ZFS support
> "for free". Didn't know about NTFS-3G - I always thought that
> it was the lack of a good NTFS driver that was the reason for
> all those NAS devices not touching NTFS.
Indeed. Some of the more esoteric FUSE FSs might be interesting too, like
gphoto2-fuse-fs (mount your digital camera using PTP protocol) if the
relevant backend stuff was done (USB commands for PTP in this case).
There's even a fuse_adfs module (in Python, sadly).
Theo
Peter Naulls
> Peter Naulls <pe...@chocky.org> wrote:
>> In both of those cases - not quite - AFAIR, the ADFS stuff doesn't have
>> support for RISC OS filetypes (simply adding ,xxx to the end when
>> appropriate), so RPCEmu won't know what to do with the files. Years
>> ago I did a small patch to Linux ADFS to do exactly this, but it
>> got lost after its submission for mainstream inclusion.
>
> Yup, I did wonder about that. Any chance of you digging out the patch?
No, it was ~10 years ago :p Anyway, it's trivial - it will be
approximately the opposite of what happens in RPCEmu's HostFS, etc.
That is look at the ADFS filetype bits, watch out for non-typed
files (very rare on RISC OS these days) and add the ,xxx bit if it's
not a text filetype.
>
> FWIW I think RPCEmu should cope if you give it the disc image as a file - it
> should emulate it as an ADFS IDE drive. I tried it a while ago and ran into
> some problems - I think Tom fixed them but I never got around to checking.
> Meanwhile I don't know what happens if you provide the HD device
> file direct to RPCEmu - ie tell RPCEmu its ADFS disc image is /dev/hdX.
> There's an outside chance it might work.
All these should work - permissions aside - looking at a drive like
that is just the same as a fixed size file, but it might depend
a little upon what exactly the driver support in RPCEmu expects.
Dave Higton
Rob Kendrick <nn...@rjek.com> wrote:
> On Tue, 01 Jul 2008 22:33:29 +0100, Dave Higton wrote:
>
> > Although I've never tried it, I had always understood that a FS
> > implemented under FileSwitch would not necessarily suffer from the 2 GB
> > limitation. An image FS would, of course. Have I not understood
> > correctly?
>
> You have not understood correctly. FileSwitch, as it is, cannot provide
> access to files more than 2GB large. It is a fundamental limitation of
> its design, and its API. Image file systems suffer the 2GB limitation
> because of this.
I see I'm guilty of not expressing myself clearly. I'm clear that
the 2 GB file size limitation remains. But the size of the drive
or partition carrying the foreign filing system isn't limited to
2 GB, if not presented as an image, is it?
Dave
Peter Naulls
It is, because in the RISC OS model, e.g. DOSFS, this is how
it's treated. IIRC, there's a diagram in one of the PRMs
about how it works. Worse, this code that needs to present
it like this needs to be in every FS that would like to use
FAT formatted discs - ADFS, SCSIFS, etc.
Rob Kendrick
> I see I'm guilty of not expressing myself clearly. I'm clear that the 2
> GB file size limitation remains. But the size of the drive or partition
> carrying the foreign filing system isn't limited to 2 GB, if not
> presented as an image, is it?
Unfortunately, due to the upside-down nature of the RISC OS file system
stack, interface device drivers are in the same lump as their "file
system" (even if they are implemented by another module) making it
tricky, if not impossible, to write a new on-disc format that uses all
the existing drivers correctly and transparently.
You could of course tie your new file system module directly to ADFS by
using ADFS's block access SWIs, but then that won't work for people with
one of the dozen variations of IDEFS, MassFS, ZipFS, SCSIFS, etc.
The reason foreign discs are "emulated" as images is to get around
precisely this problem. The cost is the limitation in maximum size.
B.
druck
> No, it was ~10 years ago :p Anyway, it's trivial - it will be
> approximately the opposite of what happens in RPCEmu's HostFS, etc.
> That is look at the ADFS filetype bits, watch out for non-typed
> files (very rare on RISC OS these days) and add the ,xxx bit if it's
> not a text filetype.
The way of handling non file typed files is to add ,lllllllleeeeeeee
extension to it, where the 'l's and 'e's are the 32bit hex values of
the load and execution addresses. I don't know if RPCEmu's filing
system supports this, but if it doesn't it should.
druck
> On Wed, 02 Jul 2008 20:25:29 +0100, Dave Higton wrote:
>> I see I'm guilty of not expressing myself clearly. I'm clear that the 2
>> GB file size limitation remains. But the size of the drive or partition
>> carrying the foreign filing system isn't limited to 2 GB, if not
>> presented as an image, is it?
> Unfortunately, due to the upside-down nature of the RISC OS file system
> stack, interface device drivers are in the same lump as their "file
> system" (even if they are implemented by another module) making it
> tricky, if not impossible, to write a new on-disc format that uses all
> the existing drivers correctly and transparently.
> You could of course tie your new file system module directly to ADFS by
> using ADFS's block access SWIs, but then that won't work for people with
> one of the dozen variations of IDEFS, MassFS, ZipFS, SCSIFS, etc.
No, thats exactly how it should work, but it doesn't need to be tied
to any one hardware driver, as they all work in the same way, it just
needs to know which one to use.
> The reason foreign discs are "emulated" as images is to get around
> precisely this problem. The cost is the limitation in maximum size.
Acorn made a decision to present the foreign format as a normal file
for ease of implementation, with the unfortunate consequence of the
2GB limit (this wasn't an issue back when megbytes were huge). But its
just as easy, if not easier for the format handler to use block level
operations, and thus be free from the file limit, able to support
foriegn formats up to the total size limit for native discs.
All thats needed is add a service call called issued before the
existing one, which passes around a DiscOp SWI number* (from ADFS,
SCSIFS, etc) and drive number, instead of a file handle. The new style
handler can claim this and use the block level access call on which
ever is the hosting hardware driver.
* The question being which SWI. There is the old deprecated
xxFS_DiscOp byte level call which we should be able to discount as I
dont think anything using it made it to 32bits. The obvious choice is
the xx_FS_SectorOp sector level SWI supported by all by existing
filing systems. RISC OS 5 ADFS implements a new xxFS_ByteOp64 64bit
call, which will be needed for any filing system that suppotrs TB
sized discs - hardware permitting ofcourse. The current RISC OS 5
implementation converts in to the normal xxFS_SectorOp call, as the
hardware is limited to 256GB (128GB useful with UDMA) so doesn't yet
need the 64bit range. I think its only DiscKnight which actually uses
this call if available.
druck
> On Tue, 01 Jul 2008 22:33:29 +0100, Dave Higton wrote:
>> Although I've never tried it, I had always understood that a FS
>> implemented under FileSwitch would not necessarily suffer from the 2 GB
>> limitation. An image FS would, of course. Have I not understood
>> correctly?
> You have not understood correctly. FileSwitch, as it is, cannot provide
> access to files more than 2GB large. It is a fundamental limitation of
> its design, and its API. Image file systems suffer the 2GB limitation
> because of this.
No, its a limitation of its current implementation. There isn't any
reason why it can't be extended to handle 64bit sizes.
>> I agree that it could all do with an overhaul; what major software
>> couldn't? But I still don't see a convincing case for replacement.
> Try comparing it to the offerings elsewhere, and you'll see it's in a
> shocking state! The file system is one of the parts of RISC OS that's
> firmly wedged in the past.
I suggest the rip it up and start again method of development is
unsuitable for this platform at this stage in its lifecycle. There
just aren't enough developers writing new code to start using these
new pie in the sky APIs.
If I can adapt my existing RISC OS code by using a 64bit variant of a
RISC OS filing system API, I'll do it. If I have to rip out all if my
filing system code and use something completely different, I'm just
not going to bother.
druck
> I would propose doing just an extension for the few calls that
> need to handle 64bit file lengths. We need to keep the old
> feature set because so many things rely on it - I don't think
> it would be sensible e.g. to try to port filecore to the extended
> API. You could of course "fake" large files with multiple objecs,
> but that sounds like one hack too much.
There wouldn't be any real need for that. If you want big file you
reformat as VFS, in the same way that if you wanted RISC OS 4 long
filenames you refomatted to Filecore '+' format.
> Software using the old API would only be able to see the first
> 2 GB of every large file, but that is not really a problem - most
> software does not have a need for large file support. DOSFS
> would be a likely first candidate to use the new API, the source
> is already available from ROOL.
It doesn't need a new API, it can work withing the exisiting one. All
thats needed is a new service call to pass a DiscOp SWI number instead
of a file handle, as I detail in a previous post.
> I think Alex Waugh's ideas are spot on for such a way forward:
> http://www.riscosopen.org/wiki/documentation/pages/FilingSystemUpdate
> I also agree with druck that at the moment, the only *real* usage
> of a 64bit enabled FileSwitch would be lifting the 2 GB limit for
> image fses. An over-ambitious "replace-the-whole-FS-stack" approach
> is just not the right answer for such a comparatively small
> "problem". IMHO of course.
What we need is the small extension to FileSwitch for 64bit file
sizes, and to plumb in a new VFS filing system at the same level as
Filecore. i.e. sitting between Fileswitch and the xxFS hardware
drivers.
What we don't need is an ambitious rearchitecturing of the entire
filing system stack, with entirely new ivory tower APIs that no
software will use - the dog is too old to learn new tricks.
>> Apart from that, the ridiculous duplication that occurs over all the
>> CDFS drivers, and SCSI drivers for that matter - all have their own
>> special way of handling ATAPI/SCSI commands.
> This would be easily solved by providing "block drivers" for the
> hardware and implement generic drivers for the things needed (which
> is basically only CDFS and CDVDBurn).
> We already have most of the necessary framework in the form of the
> SCSISwitcher. Implementing the IYONIX ATAPI system as a SCSISwitcher
> module would be a first logical step.
Agreed.
>> And let's not forget HForm - a rather more simplistic problem, and
>> can be separated from this, but all in all a bit hopeless, running
>> into integer maximums in BASIC, and never mind that everyone rewrote
>> it for their own filesystem, instead of having a comprehensive
>> and robust single program to do it.
> I guess HForm is just to be seen as "legacy". Every FS that possibly
> needs it already has a variant or three.
There needs to be one formatting code for Filecore, and for VFS, using
the block level calls from each FS. The only thing needed which we
dont currently have is a standard driver SWI to return certain device
information that the formatter needs to know in order to format the
drive to the right size.
> We just have to take care not to make the same mistake again...
>> Let's not forget file locks (no, not the ADFS locks), full permissions,
>> and smooth integration of alternate filesystems - VFAT, ext2 alongside
>> Filecore.
> Permissions is a difficult topic since there are so many
> different solutions on other platforms.
> "Smooth integration" - I have never seen the API that a Linux FS
> must use to integrate itself into the system. It would be very
> valuable to be able to easily reuse code from open source FSes,
> but is this really realistic? I would be interested to hear
> more details about this from someone who knows the FS situation
> on Unix-like OSes.
I think those heavily involved in unix porting what to replace the
current RISC OS API with complete POSIX filing system API. While
that would be nice for them, I see very little advantage to native
RISC OS programs running on a single user OS.
Peter Naulls
> I think those heavily involved in unix porting what to replace the
> current RISC OS API with complete POSIX filing system API. While
> that would be nice for them, I see very little advantage to native
> RISC OS programs running on a single user OS.
That's mostly incidental, since UnixLib has taken care of that
for a long time. The only obvious things missing are file locks
and a full range of permissions.
Rob Kendrick
>> You could of course tie your new file system module directly to ADFS by
>> using ADFS's block access SWIs, but then that won't work for people
>> with one of the dozen variations of IDEFS, MassFS, ZipFS, SCSIFS, etc.
>
> No, thats exactly how it should work, but it doesn't need to be tied to
> any one hardware driver, as they all work in the same way, it just needs
> to know which one to use.
And how exactly does it then, having been given the string "IDEFS", what
SWIs to call? At best, it has to create strings and look up SWI names.
And that doesn't always work, because there is inconsistency in how these
modules name these entry points, if they even exist to start with. I
looked into just this possibility some time ago, by comparing the entry
points for several FileCore file system driver modules.
And in any case, if this "solution" doesn't strike you as having a stench
of hack, I don't think we're going to agree.
B.
Rob Kendrick
> I suggest the rip it up and start again method of development is
> unsuitable for this platform at this stage in its lifecycle. There just
> aren't enough developers writing new code to start using these new pie
> in the sky APIs.
Of course, replacing it from scratch may actually be easier than hacking
the current mess to do what we want. I suspect very strongly that to be
the case, especially when considering the maze of assembler that
FileSwitch and FileCore are.
By comparison, MINIX's entire file system (VFS and on-disc format) comes
in at under 4000 lines of C, and is immeasurably superior to what RISC OS
has.
B.
Rob Kendrick
> What we need is the small extension to FileSwitch for 64bit file sizes,
> and to plumb in a new VFS filing system at the same level as Filecore.
> i.e. sitting between Fileswitch and the xxFS hardware drivers.
Two points:
1) This extension may be small from the API point of view, but I imagine
the assumption of 32 bit extents is rife in the source code, and would
require a large amount of work to fix.
2) We seem to be confusing terms - A VFS has nothing to do with an on-
disc format as FileCore does. FileSwitch is RISC OS's equivalent of the
VFS. (ie, a VFS handles paths, and deciding which /real/ file system
(rather than virtual one) handles specific name spaces. FileSwitch does
this triggering on the file system name prefix (such as ADFS::), where
UNIX does it on any directory, and Windows does it on a combination of
both.)
B.
Rob Kendrick
Other than a POSIX API actually being an order of magnitude simpler, and
a similar order of magnitude more flexible and reliable, there are
advantages to having multi-user aware file systems even on single-user
computers. This becomes obvious when you have network shares and want
some security from accidentally deleting system-critical files you
shouldn't have.
B.
Rob Kendrick
> The way of handling non file typed files is to add ,lllllllleeeeeeee
> extension to it, where the 'l's and 'e's are the 32bit hex values of the
> load and execution addresses. I don't know if RPCEmu's filing system
> supports this, but if it doesn't it should.
Aren't non-typed load/exec files now deprecated, in any case?
B.
druck
Yes, but that doesn't make them cease to exist.
druck
>>> You could of course tie your new file system module directly to ADFS by
>>> using ADFS's block access SWIs, but then that won't work for people
>>> with one of the dozen variations of IDEFS, MassFS, ZipFS, SCSIFS, etc.
>>
>> No, thats exactly how it should work, but it doesn't need to be tied to
>> any one hardware driver, as they all work in the same way, it just needs
>> to know which one to use.
> And how exactly does it then, having been given the string "IDEFS", what
> SWIs to call? At best, it has to create strings and look up SWI names.
> And that doesn't always work, because there is inconsistency in how these
> modules name these entry points, if they even exist to start with. I
> looked into just this possibility some time ago, by comparing the entry
> points for several FileCore file system driver modules.
The SWI call is known to Filecore as its passed up by the driver on
registration.
> And in any case, if this "solution" doesn't strike you as having a stench
> of hack, I don't think we're going to agree.
I don't think you understand the current system well enough to be able
to make such accusations.
druck
But Rob, I can't help feeling you are coming at this from the point of
view of someone who doesn't want to program for RISC OS, and would
rather you had a Unix like API as on the systems you do program for.
I'm approaching this from the point of view of a RISC OS programmer,
who is well versed in the legacy API, doesn't see it as being evil,
and is not attracted by the prospect of using an entirely different
API, no matter what claims of superiority are made.
Rob Kendrick
> The SWI call is known to Filecore as its passed up by the driver on
> registration.
So now the filing system is even more twisted with loops in it? Why
should one one-disc format implementation call out to other handlers?
Isn't that what FileSwitch /is for/ ?
B.
Rob Kendrick
> But Rob, I can't help feeling you are coming at this from the point of
> view of someone who doesn't want to program for RISC OS, and would
> rather you had a Unix like API as on the systems you do program for.
I'm not even suggesting that we should have the UNIX-style API. You're
the one you mentioned POSIX. I'm saying the UNIX style file system
structure is far superior. (ie, a VFS talks to a file system, which talks
to a block device driver) The API doesn't matter.
In any case, should a replacement stack use a POSIX-style API, it's a
trivial matter to include a compatibility layer that includes a new old-
style API for large files.
Why *wouldn't* somebody want to use a new, simpler, more powerful API
rather than one with a hundred different calls, dozens of confusingly
similar ways of doing things, which doesn't allow for future expansion in
any case?
B.