Question on behalf...

There's a long time bug in Recyclone, whereby the filer can forget a
directory or file in the Recyclone bin so it will never expire or be
deleted.

Nor can it be manually deleted from "...!Boot.Resources.!RecycBin.Bin" as
the filer sort of thinks it doesn't exist, though of course it is still displayed in Recyclone's bin.

Nothing I've tried in RISC OS will ever delete that item, all attempts obviously fail.

Anyone have any thoughts on how, from within RISC OS this errant item can
be removed?

Thanks
Dave

FWIW. Using a VRPC-DL I just access the the thing from the Windows filer
side and remove the errant item.

D.

--

Dave Triffid

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 27 Jul 2022 as I do recall,
Dave wrote:

Question on behalf...

There's a long time bug in Recyclone, whereby the filer can forget a directory or file in the Recyclone bin so it will never expire or be
deleted.

Nor can it be manually deleted from "...!Boot.Resources.!RecycBin.Bin" as the filer sort of thinks it doesn't exist, though of course it is still displayed in Recyclone's bin.

[snip]

FWIW. Using a VRPC-DL I just access the the thing from the Windows filer
side and remove the errant item.

If it can be deleted from outside the emulator, then presumably the
object does actually exist rather than just being a ghostly bug in
Recyclone's display code... which would have been my initial assumption!

Are you saying that it is not even *displayed* by the Filer in !Boot.Resources.!RecycBin.Bin, or that the file is visible but nothing
happens when you try to delete it?

--
Harriet Bazley == Loyaulte me lie ==

It is far better to be deceived than to be undeceived by those we love.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <425e9a0e5a.harriet@bazleyfamily.co.uk>,
Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:

[Snip]

If it can be deleted from outside the emulator, then presumably the
object does actually exist rather than just being a ghostly bug in Recyclone's display code... which would have been my initial assumption!

Are you saying that it is not even *displayed* by the Filer in !Boot.Resources.!RecycBin.Bin, or that the file is visible but nothing happens when you try to delete it?

Harriet.
The file is visible in the Bin when Recyclone is on the icon bar, but it
cannot be Expired, or emptied from the Bin.

It's also visible when the !Boot.Resources.!RecycBin.Bin is opened, but
will not Delete, nor will it open.

It errors with a message (Can't remember exactly) but along the line of
"File nnn does not exist."

Yes the object does actually exit, when I go Windows side and open !Boot.Resources.!RecycBin.Bin it shows in the Win filer window, and if
it's a directory the contents can be viewed, copied or deleted.

Dave

--

Dave Triffid

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 27 Jul 2022 as I do recall,
Dave wrote:

The file is visible in the Bin when Recyclone is on the icon bar, but it cannot be Expired, or emptied from the Bin.

It's also visible when the !Boot.Resources.!RecycBin.Bin is opened, but
will not Delete, nor will it open.

It errors with a message (Can't remember exactly) but along the line of
"File nnn does not exist."

It does sounds as if Recyclone has corrupted the disc records somehow in
the course of its operations, and I don't know the first thing about
them.

Have you tried DiscKnight?


--
Harriet Bazley == Loyaulte me lie ==

Questions are a burden to others, but answers are a prison for oneself.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 27 Jul, Harriet Bazley wrote in message
<5de6bc0e5a.harriet@bazleyfamily.co.uk>:

It does sounds as if Recyclone has corrupted the disc records somehow in
the course of its operations, and I don't know the first thing about them.

Have you tried DiscKnight?

If Dave's using VRPC and HostFS, DiscKnight won't be a lot of help.

Is Recyclone trying to be "clever" by hooking into the Filer, in an attempt
to protect the user from themselves? If so, presumably it's intercepting
Delete operations normally, so if it thinks the file has been deleted,
perhaps it's blocking the delete?

--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Steve Fryatt <news@stevefryatt.org.uk> wrote:

On 27 Jul, Harriet Bazley wrote in message
<5de6bc0e5a.harriet@bazleyfamily.co.uk>:

It does sounds as if Recyclone has corrupted the disc records somehow in the course of its operations, and I don't know the first thing about them.

Have you tried DiscKnight?

If Dave's using VRPC and HostFS, DiscKnight won't be a lot of help.

Is Recyclone trying to be "clever" by hooking into the Filer, in an attempt to protect the user from themselves? If so, presumably it's intercepting Delete operations normally, so if it thinks the file has been deleted, perhaps it's blocking the delete?

Another thought is it's doing something that's upsetting the VRPC filename translation. For example, if it were to rename a file
example/txt,fff/txt,fff

I could well imagine errors like 'file does not exist' because HostFS can't match up the RISC OS name with the name on the Windows side.

It's also possible that any 'cleverness' doesn't work with HostFS, because
that doesn't work in exactly the same way as FileCore filesystems (ADFS etc) that the Recyclone author was expecting.

Theo

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <CVA*JzjUy@news.chiark.greenend.org.uk>,
Theo <theom+news@chiark.greenend.org.uk> wrote:

[Snip]

Another thought is it's doing something that's upsetting the VRPC
filename translation. For example, if it were to rename a file example/txt,fff/txt,fff

I could well imagine errors like 'file does not exist' because HostFS
can't match up the RISC OS name with the name on the Windows side.

It's also possible that any 'cleverness' doesn't work with HostFS,
because that doesn't work in exactly the same way as FileCore
filesystems (ADFS etc) that the Recyclone author was expecting.

Theo

Mmnnn! Interesting thought Theo, but an ointment fly has arrived.
But your note gives me thoughs...

Often it's a directory that will not delete so a file is not involved,
though of course errant files might be present in the directory.

Time for a test or two methinks. :-)

1). Create a bog standard text file "Test1" Save it, then delete it.

It's now in the Recycler Bin.

Rename it to Test1/txt,fff press Return.

Oeer! That interesting, the File name is now Test1/txt,fff/txt the final
txt has been added by RISC OS not me.

The file is now untouchable, it cannot be loaded into Zap, nor can it be renamed or deleted.

'HostFS::HardDisc4.$.!boot.Resources.!RecycBin.Bin.Text1/txt,fff/txt' not found.

2). Now for a Directory test: :-)

Directory with a text file inside it.

Delete to Recycle bin.

Change the text file name Test1/txt,fff the filer adds /txt

Now the directory will not delete, copy or move.
Interestingly, the directory can still be opened to show the text file in
the filer window, but obviously the text file won't open.

Seems like you might have hit the nail... Though I have no idea how in
normal use the file name might get munged.

Interesting though. :-)

Thanks
Dave

--

Dave Triffid

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 28/07/2022 10:40, Theo wrote:

Another thought is it's doing something that's upsetting the VRPC filename translation. For example, if it were to rename a file example/txt,fff/txt,fff

Also lots of characters which either are not allowed in filenames or may
not be translated consistently. If you are using anything other than alphanumerics, dash and underscore you are going to have trouble on
foreign filing systems.

---druck

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <tbuqbs$38bmf$1@dont-email.me>,
druck <news@druck.org.uk> wrote:

On 28/07/2022 10:40, Theo wrote:

Another thought is it's doing something that's upsetting the VRPC
filename translation. For example, if it were to rename a file example/txt,fff/txt,fff

Also lots of characters which either are not allowed in filenames or may
not be translated consistently. If you are using anything other than alphanumerics, dash and underscore you are going to have trouble on
foreign filing systems.

---druck

Indeed.

However, the main question remains unanswered.

If for whatever reason an event happens, how in RISC OS do you Delete the errant item?

Dave


As noted previously, it's easy for me, I just drop out of RISC OS into
Windows, go to VRPC...'HostFS::HardDisc4.$.!boot.Resources.!RecycBin.Bin'
and delete from there.

D.

--

Dave Triffid

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 29 Jul 2022 as I do recall,
Dave wrote:


[snip]

However, the main question remains unanswered.

If for whatever reason an event happens, how in RISC OS do you Delete the errant item?

As noted previously, it's easy for me, I just drop out of RISC OS into Windows, go to VRPC...'HostFS::HardDisc4.$.!boot.Resources.!RecycBin.Bin'
and delete from there.

It sounds from what has been said that the problem is being caused by
using Recyclone on HostFS in the first place and that in native RISC OS
it wouldn't be an issue. :-(

You've got two rival filing systems with different naming conventions
confusing one another, plus a program that assumes it is dealing
exclusively with the RISC OS Filer.


--
Harriet Bazley == Loyaulte me lie ==

A statement of fact cannot be insolent

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 29/07/2022 06:21, Dave wrote:

However, the main question remains unanswered.

If for whatever reason an event happens, how in RISC OS do you Delete the errant item?

You don't, you have to go to the native filing system, find the
offending file and delete it from there.

---druck

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)