In article <CVA*
Jz...@news.chiark.greenend.org.uk>,
Theo <
theom...@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