Deleted Image FS remains accessable

If an image file which contains an open file is deleted (which requires the image to be on a filing system that supports unlinking open files) the contents of the image file remains accessible, except for listing the root directory of the image file.

If the image file is replaced with a directory, the directory can be listed but other operations are applied to the image. If the image file is replaced with another image, full access to the contents of the original image is restored.

Once the files are closed normality is restored, potentially losing the files written to the old image.

that supports unlinking open files

Therein lies the problem. One can’t delete opened files under RISC OS (I don’t think even Econet permitted that to happen) so attempts to do so are likely to cause weird things to happen.

Once the files are closed normality is restored,

I’d be inclined to blame the underlying filesystem more than RISC OS.

Two questions:

• Why is it allowing an open file to be deleted in the first place?
• Does it pass back any sort of error back upon file deletion and further attempts to access the now deleted file? It sounds like the two (image FS (FileSwitch?) and underlying FS) are getting completely out of sync with each other.

What image FS are you using? SparkFS tries to close files when “doing nothing”. I created “test/zip” and put a few files in there. The handle was released in a couple of seconds. Further access to the archive reopened the file, briefly.
More specifically, going to the command line and deleting the file caused the directory viewer to disappear when I went back to the desktop. The image filing system was aware that its file had gone.

One can’t delete opened files under RISC OS

Whilst is is documented that OS_File 6 is documented as giving an error if the file is open “An error is generated if the object is locked against deletion, or if it is a directory which is not empty, or is already open.”, but this is not required of FSEntry_File 6 “You should return an error if the object is locked against deletion, but not if the object does not exist.”

It is possible to delete open files on ResourceFS (using ResourceFS_DeregisterFiles), in that case that is a use after free bug resulting on arbitrary file contents, data aborts, or reading memory mapped IO.

Why is it allowing an open file to be deleted in the first place?

Because that’s what Linux does, and it’s a thin wrapper over Linux. RPCEmu HostFS is similar.

Does it pass back any sort of error back upon file deletion and further attempts to access the now deleted file?

No the file is not deleted until all file handles (and other references) are closed.

What image FS are you using?

I’ve tested with DOSFS and TBAFS.

Did you have a file in the image open? If so, and the image is on FileCore I get an error.

FSEntry_File 6 “You should return an error if the object is locked against deletion, but not if the object does not exist.”

I think we are running into a grey area here thanks to some rather bad wording in the PRM. If the file does not exist, FSEntry_File 6 does not need to return an error; but it should return an error if the file is locked against deletion.
Would one consider a file being open as requiring that it be considered locked?

Because that’s what Linux does,

Then it will need to be handled as an emulation-specific issue.

RPCEmu HostFS is similar.

Oh, I’ve run into HostFS before. I have a program that creates a file, sets its type accordingly, and then writes data to it.
Blows up on the emulator.
Setting the type of a file changes the actual underlying file (“something” becomes “something.txt” or whatever) and HostFS doesn’t bother to consider the two files to be identical. I’ve even managed to get situations where it simply can’t see some files (because it presents them as the same under RISC OS, and then can’t tell them apart itself.
These are not RISC OS problems, these are emulation problems.

Did you have a file in the image open? If so, and the image is on FileCore I get an error.

Tested with SparkFS. Created “__test/zip”. Copied “35LCD” (my little LCD’s mode file) into it. Opened a handle to the 35LCD file.
Files currently open – __test/zip and 35LCD.
Trying to delete __test/zip files (because it’s open).
Closing the handle to __test/zip works, but as a consequence SparkFS also closes the handle to 35LCD. This may be a problem for whatever has access to the opened file, but it does mean that one should not have a file open in an image file that is in a position to be erased.

And, of course, we could debate the fact that the Wimp really ought to be passing around a lot more informational messages than it does (files closed, alphabet changed, etc) but that’s a whole different topic. ;-)

It is possible to delete open files on ResourceFS (using ResourceFS_DeregisterFiles)

That is not deleting a file. That is the equivalent of pushing eject on a floppy drive or yanking a USB stick. There’s nothing the filing system can do about any of these scenarios.

You appear to be describing an emulator bug.

That is not deleting a file. That is the equivalent of pushing eject on a floppy drive or yanking a USB stick.

That should, and does, result in an a request to re-insert the media or an error being raised, unlike the behaviour of ResourceFS which try to return whatever happens at that memory address.

Would one consider a file being open as requiring that it be considered locked?

The PRMs define “locked” as meaning protected against deletion, so no.

Re RPCEmu HostFS:

Setting the type of a file changes the actual underlying file (“something” becomes “something.txt” or whatever) and HostFS doesn’t bother to consider the two files to be identical.

RPCEmu HostFS doesn’t use dot-prefixed extensions, are thinking of VirtualRPC HostFS? (There are at least 3 programs by the name HostFS)

One can’t delete opened files under RISC OS (I don’t think even Econet permitted that to happen)

Judging by reading the source both Sunfish and ex-Acorn NFS allow deleting (not just unlinking) open files, but more importantly nothing done under RISC OS can stop a unix program deleting a file that is open in RISC OS.

There is also a pure RISC OS of way creating this mess, first open an image over ShareFS then rename the directory containing the image directly on the underlying filesystem. There also is a similar inconsistency in the PRMs as to whether renaming an open file is permitted.

To prevent unlinking open files there are 4 approaches I can think of:

1. Check the path requested against Fileswitch’s list of open files. If the the file has been renamed outside of the current instance of RISC OS this will apply to the wrong file.
2. Check the device and inode numbers of the file to deleted against the list of open files.
3. Check if there any advisory locks on the file, if none unlink the file. This has a
4. Open the file for writing, place an advisory write lock, if successful unlink the file. This does not work for files without write permission.

Approach 1 provides full compatibility with a single RISC OS computer without causing side-effects such as being being unable to delete a different path which contains alternative links to open files.

Approach 4 is compatible with multiple instances of RISC OS, but only works where the files have write permission.

Does any other program fail like Fileswitch, that is fail if a open file is deleted (or renamed) but work correctly if directory containing the open file is renamed on the same instance of RISC OS?

Does any (set of) program attempt to delete an open file and malfunction if it succeeds in deleting the open file?

I propose extending FSEntry_File and FSEntry_Open to return a persistent file identifier that Fileswitch and other programs can use to detect if a file has been replaced, and to find an appropriate handle when a moved image is found.

Tim correctly pointed out

[Eject] should, and does, result in an a request to re-insert the media or an error being raised, unlike the behaviour of ResourceFS which try to return whatever happens at that memory address.

This is indeed a long-standing ResourceFS problem which is not specifically to do with your original subject of images – it has always allowed you to Deregister an open file. This is because it does not keep any record of which files it has opened (and, equally, FileSwitch which does know gets no chance to object to the file disappearing).

ResourceFS could keep a record (best option), or it could enumerate open files on Deregister. It could then mark such open files as invalid. (I don’t think it’s worth arranging for ResourceFS to ask FileSwitch et al for permission via ServiceCall or equiv.)

However, there are things that use magic knowledge about ResourceFS to access data directly. These things are unlikely to notice files closing or new ServiceCalls. In other words, it was always an API design flaw. It’s very much a special case.

both Sunfish and ex-Acorn NFS allow deleting (not just unlinking) open files…ShareFS

All bets are off with ‘remote’ filing systems. The remote machine can be unplugged at any time. One would hope the local FS would notice and return a Channel error or more verbose equivalent. This can apply to a Host filing system too, as you point out.

There also is a similar inconsistency in the PRMs

Well yes, about everything.

Rick helpfully experimented

SparkFS also closes the handle to 35LCD

An arguable position, but as we’ve discussed regarding StopClose0 and CloseHook – closing someone else’s file especially with handle reuse is a very bad idea. The now-inaccessible file should go into a zombie state and the FS return a Channel error or equivalent.

(I keep saying Channel, but I can’t remember why. Econet?)

Tim concluded

I propose extending FSEntry_File and FSEntry_Open

Which isn’t going to help any existing FSes, if I understand you correctly.

I keep saying Channel, but I can’t remember why. Econet?

Econet probably did, but it’s origin was what the tape filing system used to say if you used a “channel” (file handle) that you hadn’t yet opened.

Real blast from the past there. I propose we resurrect Channel to give as the error for all “some twat closed your file so you’re screwed” situations. :-)

Is Channel error Nº5?

Is Channel error Nº5?

The door is that way —→

On topic of Image filing systems leftovers, I just noticed today that if I perform an “Open directory” in a StrongHelp document and quit StrongHelp the directory is left on screen.