Cannot change file attributes

RPCEmu does not allow me to change file attributes for files in HostFS.

What I would like to do is to create a file in RISC OS that can be used in the Windows10 Host.

So I created a file in ArtWorks, then exported it as a JPEG to the root of HostFS with file name pic/jpg.Although it is in the HostFS directory in RISC OS it does not appear in the HostFS directory in MS Explorer on the Windows side.

When in RISC OS I tried to change the file attributes, eg to Public it always reverts to Private.

I am using RPCEmu version 0.9.1

John

So I created a file in ArtWorks, then exported it as a JPEG to the root of HostFS with file name pic/jpg.Although it is in the HostFS directory in RISC OS it does not appear in the HostFS directory in MS Explorer on the Windows side.

Remember that files will have the type appended to the name on the host system, so the Windows file will actually be called pic.jpg,c85. If you’re viewing the files in a load dialogue for an application which is filtering on extensions (most software does), then it won’t show up. You will probably need to rename the file from the Windows side to make this work.

Unlike other systems, which check MimeMap and only add the ,c85 if the /jpg extension doesn’t match the RISC OS type, HostFS adds the filetype to every file. Rumour has it this is by design, but it’s a massive pain in the rear for any kind of cross-platform work. I’m generating a fair few screenshots in PNG format at present, for use on Linux, and I have to have a Linux-side directory viewer open to rename each and every one; in contrast, files saved from the native box via Sunfish work straight off, because Sunfish looks at the /png extension, realises that it expresses the RISC OS type, and leaves the name alone.

Although it is in the HostFS directory in RISC OS it does not appear in the HostFS directory in MS Explorer on the Windows side.

I think this is because there are actually two HostFS folders – one in C:\Program Files, and one in C:\Users\<foo>\AppData. Modern versions of Windows don’t like programs which write to their installation folder, so instead the writes get directed to the user’s AppData folder. I think this can also cause a related problem, where if you add/change a file in Program Files then it might not appear in RPCEmu.

Changing the RPCEmu installation folder permissions so that it’s owned by your user account should allow RPCEmu to modify its contents, stopping the duplicate HostFS problem (although you may also need to manually clean out the relevant AppData folder to avoid any confusion)

https://superuser.com/a/1141616

When in RISC OS I tried to change the file attributes, eg to Public it always reverts to Private.

I think this one is deliberate as well.

RISC OS attributes (apart from private read/private write) don’t map cleanly to file attributes on other systems, and HostFS is relying on the host OS to store file attributes. I seem to recall being told (by Timothy Coltman? Memory like a sieve…) that HostFS doesn’t alter file attributes at all.

Thanks for the replies everyone. I set the permissions on the HostFS folder to full control for all users and the file has magically appeared as pic.jpg,c85 (as predicted by Steve). I have now renamed it and it is in use as my Zoom background.

Unfortunately after stopping RPCEmu and attempting to restart it the HostFS directory has disappeared and it wont boot. It seems to have disapeared on the windows side also. That should teach me not to mess with things I don’t fully understand!

Seems like a good opportunity to install the latest version.

I seem to recall being told (by Timothy Coltman? Memory like a sieve…) that HostFS doesn’t alter file attributes at all.

Correct – all file attributes (locked, public, private, etc) are ignored when mapping file details between emulator and host.

I have a patch in development that extends HostFS to support multiple drives with custom mount points – I’ll see if I can include something for file attributes. I’m not sure how it would/should work, though.

I have a patch in development that extends HostFS to support multiple drives with custom mount points

If you are interested in tackling other things from my RPCEmu wishlist, just let me know :-)

I’ll see if I can include something for file attributes. I’m not sure how it would/should work, though.

My initial thoughts are:

• Owner read
  Not mapped: all files are assumed to be readable.
• Owner write
  Map to “current user write” or perhaps “owner write”¹ on host OS.
• Public read/write
  Not mapped.
• Lock
  One-way mapping (i.e. RISC OS can see – but not alter – the “locked” status).

How “Locked” is handled may need to depend on the host OS. For example, on macOS a “locked” file is locked against alterations as well as against deletion: this equates to a RISC OS setting of “Read-only, Locked” (and hence you cannot allow RISC OS to alter this setting). Likewise, the Windows “Modify” and “Full control” permissions allow writing and deleting, but there is no way of representing “read-only but can be deleted” on Windows.

¹ Odd things can happen if the current user isn’t the owner of the file.

I think it’s probably fairly easy to map between RISC OS and Unix-based systems like OS X and Linux (see here for an introduction: https://www.linode.com/docs/tools-reference/tools/modify-file-permissions-with-chmod/):

• Owner read maps to user-level read (toggles u+r/u-r).
• Owner write maps to user-level write (toggles u+w/u-w).
• Public read maps to other-level read (toggles o+r/o-r).
• Public write maps to other-level write (toggles o+w/o-w).

On a Mac at least, Lock maps to the UF_IMMUTABLE file flag (see: https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/chflags.2.html).

If you are interested in tackling other things from my RPCEmu wishlist, just let me know :-)

My main areas of interest are Mac support, HostFS and another patch I have in the pipeline that will allow you to run different versions of the OS/different hard drive images/etc using one copy of the emulator (so you can easily switch between, say, 3.70 and 5.24). Sadly the last time I used RISC OS/my Risc PC properly was 1998, so I’m rather rusty when it comes to that side of things!

It would be interesting to see your wishlist – why not share it with the RPCEmu mailing list?

Unlike other systems, which check MimeMap and only add the ,c85 if the /jpg extension doesn’t match the RISC OS type, HostFS adds the filetype to every file. Rumour has it this is by design, but it’s a massive pain in the rear for any kind of cross-platform work. I’m generating a fair few screenshots in PNG format at present, for use on Linux, and I have to have a Linux-side directory viewer open to rename each and every one; in contrast, files saved from the native box via Sunfish work straight off, because Sunfish looks at the /png extension, realises that it expresses the RISC OS type, and leaves the name alone.

I completely agree, having to rename the files all the time on the host side is a real pain.

I have VRPC (not emu, but it sounds similar) on a laptop, but it’s only used away from home. Most file manipulation is done through Omni/LanmanFS. However sometimes I copy files to the ShareFS share, in particular when I’m copying applications.

Somewhere along the line I end up with two of each file, one correct, and the other showing DEADDEAD, and usually 0 bytes in length. It’s irritating, nothing more, but I’ve often casually wondered WHY?

How “Locked” is handled may need to depend on the host OS.

May? Will!

FAT is a much simpler system. You have a Read Only bit, an Archive bit, a System bit, and a Hidden bit.

File is always readable under FAT. If the Read Only bit is at, it’s not writable.

Hidden isn’t terribly useful.

Archive – apparently this is set when a file is created or modified (incremental backup software can look for this bit set, copy the file, and amend the directory entry so the bit is unset). Is this done automatically by the filesystem?

System. Perhaps this could be diddled with in order to mark a file as “locked”?

So we can support R[W][L]/

As for public permissions? Probably best to have a configuration setting to choose between “the same as private” and “none”?

It’s irritating, nothing more, but I’ve often casually wondered WHY?

I wonder how ShareFS creates files?

Something that affected one of my programs was creating a new file, setting its type, and then writing to it. This is a completely innocuous operation on real RISC OS, however on emulation giving a file a type may well cause the underlying filename to change. If the FS doesn’t keep track of this and quietly reopen the file in the background, it’ll end up trying to write to a bogus handle.

My main areas of interest are Mac support, HostFS and another patch I have in the pipeline that will allow you to run different versions of the OS/different hard drive images/etc using one copy of the emulator (so you can easily switch between, say, 3.70 and 5.24).

I think the UI that Sarah Walker did for Arculator v2 to configure different machines is a great idea. I guess your “another patch” provides similar facilities.

It would be interesting to see your wishlist – why not share it with the RPCEmu mailing list?

I think I shared it there some time ago (but could not find it in the archives), but I am working on a new one real soon now :-)

The two most important points on it would be

1. Support for MimeMap on HostFS (see Steve Fryatt’s comment above for good reasons)
2. Fix the bug that stops Mauser from working (Mauser is IMHO the most important tool in RISC OS world for both ease-of-use and power-user-needs)

But I have to say that the past development work in recent times – switching to Qt, make networking much easier, provide “Easy-Start” bundles – was great progress overall.

Unlike other systems, which check MimeMap and only add the ,c85 if the /jpg extension doesn’t match the RISC OS type, HostFS adds the filetype to every file.

Unfortunately the Mimemap module is unsuitable for any filing system which RISC OS expects to boot from.

Rumour has it this is by design, but it’s a massive pain in the rear for any kind of cross-platform work.

A happy side effect of not doing this means that files in hostfs can be happily moved to arculator and used in server directories for ftp and nfs (using ftpc client with the add ,xxx option)

I have a patch in development that extends HostFS to support multiple drives with custom mount points – I’ll see if I can include something for file attributes. I’m not sure how it would/should work, though.

Before you go down this route too far, can anyone give any examples of what anyone is actually using these in RISC OS for anyway?

Note the initial use-case mentioned at the start of this thread, would have been bogus.

I just hope changes don’t break what is working well. Copying from side by side RPCEmu’s Hostfs works well from the Linux filer.
A long time ago I looked at the ADFS fs for Linux, it does attributes, though I noticed files on a round trip had minor attribute change, nothing to bother normal RISC OS useage.
Steve, you could install/use Thunar file manager and get bulk renaming done.

I am new to RPCEmu, I like how you can get longfile names for RISC OS 3.7 with hostfs, great work area, and just use hd4 for !Booting and holding modules and binaries with short names in handy places.

Unfortunately the Mimemap module is unsuitable for any filing system which RISC OS expects to boot from.

So it could be an option: off on the boot disc, but configurable for other HostFS mounts. I see there’s also a patch for multiple HostFS mounts being proposed, which would make this possible.

A happy side effect of not doing this means that files in hostfs can be happily moved to arculator and used in server directories for ftp and nfs

Also true for files which are to be zipped up using the GCCSDK zip tool, although being aimed at RISC OS these tend not to have dot extensions anyway. I seem to recall that the behaviour is optional on a mount-by-mount basis in at least Sunfish, although I’d need to access the front-end to check that.

Steve, you could install/use Thunar file manager and get bulk renaming done.

I don’t see how that would help: I’m usually looking at single files.

In the case of the PNGs referred to above, I will be working on an XML document on the Linux side¹, drop into RISC OS to grab a screenshot with Snapper, then return to Linux and reference that file in the XML document… after renaming it. Then write some more of the document, return to RISC OS for the next screenshot, and so on.

¹ Unfortunately, Linux has better text editors available for this kind of thing, and the Perl that’s turning the XML, images and so on into an HTML document would probably stretch what RISC OS can do, too.

Unfortunately the Mimemap module is unsuitable for any filing system which RISC OS expects to boot from.

I don’t understand that comment, in multiple ways. But I am very certain that no native RISC OS file has an extension separator, so where does MimeMap come into play at all? All files relevant for !Boot will have a ,xxx extension on HostFS.

Of course, with more flexibility, there is more room for user error. So you can trade user frustration (because he broke things himself) vs. user frustration (because he cannot easily exchange files between native and emulated environment). I never brake things myself (OK, that might be a slight exaggeration…), so I choose MimeMap support anyday.

drop into RISC OS to grab a screenshot with Snapper

My Peppermint Ten has a default screenshot app similar to snapper except I think it saves a PNG. At least when I told it to load the snapshot into firefox it was then available to save as PNG. But maybe it is the further editing of the image you miss?

The problem of taking a file,png into RPCEmu RISC OS from what I’ve seen needs the file to be stripped of the extension and have the filetype set, allowing RISC OS useage and then it also just appears in the hostfs with just one ,png on the way out.
I’ll have to have a play, but it sounds like an an obey file (or two) using *Repeat could check a working directory for any files ending /png and rename and type them. I guess a BASIC program could do the whole of mimemap as well, actually I think utilities like this are already around.

Edit: OK I see now, it is not so much the dos extension, but any files for export then need to be set back to type fff so you dont get the ,filetype added.
Maybe a transit directory so everything in it can be set from and to fff. Two Obey files using repeat and settype in a way they can be easily run?
Further Edit:
An application directory for eg !SetFFF placed in any directory to click on to set files in that directory to Text
Inside is the (Obey file) !Run with the following

|  Purpose of this Obey file is to set (files) filetypes in the parent
|  directory to Text for export to Linux to avoid the comma extension.
Set Alias$TextType SetType %%0 Text
Repeat TextType <Obey$Dir>.^ -files

You could use multiple copies in directories with names like sprite png jpeg for later reference to the filetypes should that situation arise.

I think the Linux filer would have to know the difference between the destination being another hostfs or not otherwise.
Mmmm, I suppose a bash script could do the job for exporting by using a combination of copying and trimming comma extensions.

My Peppermint Ten has a default screenshot app similar to snapper except I think it saves a PNG. At least when I told it to load the snapshot into firefox it was then available to save as PNG. But maybe it is the further editing of the image you miss?

I’m taking screenshots of RISC OS applications, because I’m writing about RISC OS. A Linux-side screenshot tool would be absolutely no use to me, because it wouldn’t know where the windows were on screen, or understand how to hide the mouse pointer, or any of the other things that Snapper can do while running on the target OS.

Taking snaps on the Linux side can be useful when grabbing images of full-screen games and the like; I do that using The Gimp, usually.

OK I see now, it is not so much the dos extension, but any files for export then need to be set back to type fff so you dont get the ,filetype added.

That sounds quite complicated, given that we already have a proven solution which is used by several network filesystems.

On RISC OS, PNG images have a filetype “PNG”, which is &B60. MimeMap adds the knowledge that type &B60 has a DOS extension of /png. This allows us to make the following decisions when mapping filenames to the host side:

In other words, if the filename includes a filetype in the form of a DOS extension that MimeMap understands, then the filing system doesn’t mess with the filename on the host side. It works; the RISC OS side sees the correct type, and so does the host – with no renaming required.

What HostFS does is the unnecessary belt and braces of

As Peter notes, this might not be an option for the boot disc. But if the proposed addition to HostFS to support multiple mounts is added (something that many people are asking for), then you just turn it on for specific directories. In my case, HostFS.$ contains host-side symlinks to folders where data is transferred (folders that are really NFS mounts, in fact); I would simply mount those separately and turn MimeMap type handling on for them.

Unfortunately the Mimemap module is unsuitable for any filing system which RISC OS expects to boot from.

I think you’ve misunderstood the suggestion. Clearly using the mimemap module is foolish, because you won’t know what mappings to use until the module has started (and has loaded the mappings file from the boot drive). But there’s nothing stopping RPCEmu from using the mimemap file directly.

I.e. in the host-side mount configuration, each mount would have a set of properties which control how filename/filetype/file attribute mapping is performed. Options could include “apply suffixes for everything” (i.e. current behaviour), “pass-through” (for when RPCEmu is running on RISC OS), “use extended file attributes” (like Timothy Baldwin’s RISC OS-on-Linux port), or “use mimemap” (with a path to a host-side mimemap file).

Obviously for now people are mainly interested in “apply suffixes for everything” and “use mimemap”.

Taking snaps on the Linux side can be useful when grabbing images of full-screen games and the like; I do that using The Gimp, usually.

You make it sound like you cant do an area grab, as I said, the one I have can do everything snapper does, except for choice of image type, maybe just PNG, unless there are hidden settings, I dont see why you couldn’t grab an area of RPCEmu without the mouse pointer, you select the area you want.
You are making me doubt even this, I will check when I get back off my Iyonix. (-:

Edit: no it works either full screen, a selected window (ie rpcemu)or region (selected area)
It looks like this app is dependent or part of xcfe. screenshooter
A quick google shows there are many available , Kazam, Shutter(also has image editing), gnome-screenshot.
Lucky that I got one by default with the (light by comparison) xcfe desktop.

Further Edit: I see what you mean about the mouse pointer, a bit messy in comparison, you have to move it off out of sight say to the bottom left, then press ctrl-end before doing the capture, a click in RPCEmu window brings pointer back again.