USB files on Pi and VRPC

I am sure this must have an easy solution, but I cannot find it. ;-(

I want to use a USB stick ¹, with RO files, from a Pi with RO 5.21 and from within VRPC with RO 6.10 using DrivePop to mount it.

I can save files successfully from either and they are correctly typed and displayed in the Filer, but when viewed on the other system files are text with extensions. I will not give the detail unless it is important.

My suspicion is that I am encountering incompatible MimeMap implementations. Certainly, the VRPC version is 0.31 (20 Apr 2008) and the Pi is 0.16 (14 Apr 2012). *MimeMap does not present the information in identical format and, of course, the listed types are not the same. I have not delved into !Boot to inspect the MimeMap files directly, yet.

I have noted, but not used, some attempts at comprehensive MimeMap files and !MimeMan, but I judge that that the problem does not lie there.

Would replacing either MimeMap module with a copy of the other help?

¹ I might also want to use a USB hard drive or an SD card via USB. For these, I think I know I need to format as FAT32 first.

I think your issue is that files on the Pi are saved in native RiscOS ADFS format, whilst the files on VRPC are saved in HostFS format (which is basically DOS, with some comma extensions).

Can you not use ShareFS to transfer the files from one to the other. It should work without problem.

Alternatively, you could ‘zip’ the files up (say, using SparkFS or ArcFS) and then put the ‘archived’ files on the USB sticks. Each system should read the content of the archives with no problems (but may need some help in recognising the archive files as such)

That probably explains it, thanks.

I have been happily transferring files with ShareFS for a good while. What I want is to be able to use my development files on either type of machine without having to copy them. Then I can have a master copy on a stick and keep backups wherever. ShareFS is too slow for my purposes.

I have also transferred files satisfactorily in zips, but as you surmise, there is always a bit of renaming or settyping to get them seen.

I think I will investigate ADFS mounts in VRPC, and whether they can be removeable.

ShareFS is too slow for my purposes.

The problem is, you are stuck with RISC OS to emulated RISC OS via an intermediary. It may be possible to share from a RISC OS machine to something that Windows can mount (I used to use !Samba) but, as you’ve noticed, things are less rosy when going from a system that makes use of metadata to hold filetype to a system that uses an extension to do the same thing.

Maybe a hybrid might work for you? Continue using ShareFS, but instead of copying across each file, copy across an archive. I recall when I used to use Samba (2001-2003) it as pretty slow at initiating the transfers (so copying an app would take a long time – and being on a RiscPC that could probably just manage to saturate its 10mbit interface wasn’t a help either!) however once both ends were happy, the actual data transfer went pretty quickly.
So if you find ShareFS to be slow, try using an archive. An added benefit is less farting around outside of the RISC OS environment.

I have also transferred files satisfactorily in zips, but as you surmise, there is always a bit of renaming or settyping to get them seen.

ProTip: If you are using SparkFS, you can just drag any old file to the SparkFS icon. If it is an archive, it’ll be typed appropriately and opened.

I think I will investigate ADFS mounts in VRPC, and whether they can be removeable.

Wouldn’t this be “a file that looks like a disc” instead of “a disc that is a disc”?

Thanks for the suggestions – though I have been dragging archives to SparkFS to settype them for a very long time.;-)

Now that I understand, I think I am barking up the wrong tree.

Just to clarify, Basalt is assembled in the BASIC assembler. It has 270 files that are included as libraries – an arrangement that is so convenient I am loath to change it. The speed of the file system is important: on an SA-RPC it took about 30 sec; on a aging XP with VRPC and an SSD it takes about 5 sec; on a new W8 with SDD is about a second. Over ShareFS with any it is more like minutes.

The idea of using a zip had occured to me, but SparkFS does not support Renaming of files in zips – which has to happen from time to time. A long while back I had a little Alias that did Copy/Delete instead. Perhaps native Spark archives would work, but I do not think any other image format has the proven reliabilty.

A quick look told me that there is also no way to use ADFS discs under VRPC.

“A quick look told me that there is also no way to use ADFS discs under VRPC.”: but you can under RPCEmu, if you use RISC OS 4 (and, I believe, 6) ROMS. Hard disc images up to 1GB are available ‘off the shelf’ at http://www.marutan.net/rpcemu/ . I don’t know whether RPCEmu’s HD4 can be seen by ShareFS as I’ve never tried it; it definitely isn’t visible over a LanMan98 network. The RPCEmu archive might shed some light:
http://www.riscos.info/pipermail/rpcemu/

Disc image – not disc. VRPC has them, too.

Use a DOS image file system :)

Ah – I stand corrected!

Would X-Files work – It seems to work ok with HostFS with RSqrl RO4.02/5.19/5.21.

Heu, XFiles is not compatible with RISC OS 5…
http://www.riscos.info/index.php/X-Files
?

XFiles is not compatible with RISC OS 5…

It was 32-bitted by, IIRC, David Holden of APDL for using in his CD software distribution.

Anyway, I have a copy that works and see no reason why it cannot be made available to you.

Received. Good to know: it’s a very useful tool.

I said:

I do not think any other image format has the proven reliabilty.

My memories of X-files place it in the unproven group. Apart from needing a 32-bit version, how solid is it?

My memories of X-files place it in the unproven group. Apart from needing a 32-bit version, how solid is it?

My experience puts it in the not-totally-reliable category. But to use to write to media such as CD or DVD, the files don’t suffer from subsequent corruption. That’s the sort of thing I would use it for, but possibly it’s not suitable for your proposed application!

I think I judge X-Files that way because it is supplied with a recovery program. ;-)

Spark archives, like Zips in SparkFS, do not support Rename.

Another possibility is ArcFS. I have not used this for a very long time, but once it was my standard archiver. What is the current status, both regards to 32-bit and commercial availability? I have searched, but only found the read-only version so far.

Perhaps I should use StrongHelp images. ;-)

Perhaps I should use StrongHelp images. ;-)

:-)

Well, if you do, be sure to use the latest alpha or you may have trouble deleting stuff.

I would recommend using TBAFS (http://www.tbasoftware.co.uk/p/downloads.html) instead of X-Files. The X-Files writeback cache was always broken, and if you disable the cache, it is very slow.

Maybe Squarc (by Steve/7th Software) is an option, too?

… or DOS images (very solid).
TBAFS is a good choice.

… or DOS images

Doesn’t preserve file type. Some are “known” (*DosMap), the rest…?

@ Steffen

I have previously used TBAFS to download. The only version I have, or can find, is dated 2011 and comes with a warning “we would not recommend you store anything particularly valuable in it”. It also says that it will not run on 26-bit systems, although it seems to work in VRPC. Are TBA still supporting it? All this doubt does not put it in my “proven” category. ;-(

Squarc is an archiver, not an image filing system. There are other applications of long-standing that can do a similar job.

@ David

As I have always understood it, DOSFS truncates names to 8 characters – does it still? How would you propose I go about using it for my particular problem?

@Fred

What is wrong with StrongHelp? I do not use a very up-to-date version, but I have been deleting files without trouble for years. In case of doubt, I am not serious about using it for my current problem. ;-)

I have previously used TBAFS to download. The only version I have, or can find, is dated 2011 and comes with a warning “we would not recommend you store anything particularly valuable in it”. It also says that it will not run on 26-bit systems,

I have just downloaded it from the link given, using Linux and, after jumping through a few hoops, got it running!

There is a separate 26-bit version available.

I did not see the warning you refer to, but did see that 1.03 has a bugfix.

What is wrong with StrongHelp? I do not use a very up-to-date version, but I have been deleting files without trouble for years. In case of doubt, I am not serious about using it for my current problem. ;-)

From the release notes:

The most important is fixing the deletion of directories. This didn't
work correctly due to a design flaw in the ImageFS, which causes reading
filenames from a directory to fail when objects are deleted (point where
to continue is not correct).

To see the effect, copy StrongED's StrongHelp manual to the ramdisc and
open it by Shift-double-click. Then delete !Ref_ and see what happens.

This is changed in 2.88 and now deletions seem to work correctly, but
please try this yourselves and let me know how you get on. Note that the
directory needs to have a large enough amount of items inside it, at
least > 20.

The warning about TBAFS is on the blog page announcing it.

I expect that I have never tried to delete a StrongHelp directory of that size. I do not use alphabetical directories, but do use prefix ones.

Doesn’t preserve file type. Some are “known” (*DosMap), the rest…?

It does, even if not ‘DosMapped’.
How, is another question :)

As I have always understood it, DOSFS truncates names to 8 characters – does it still? How would you propose I go about using it for my particular problem?
Long file names works here.

The problem is that we don’t have a lot of tools to make DOS images

Solution
Fat32Formatter can format an image file (see here: https://sites.google.com/site/jeffreyadoggett/)
Don’t forget to apply the fc8 filetype to the file.
Nota: FatFsck works too.

And if you have really big problems, a tool like TestDisk (http://www.cgsecurity.org/wiki/TestDisk) will be able to save your data. It really should be compiled for RISC OS :)

Wish
Of course, the best solution would be to have tools to make and mount filecore image files. Then, it would be also possible to read ROOL USB/SD images directly. And perhaps even to use DiscKnight to check them.