RISC OS wish list

File system

• CDFS (2013-05-15) - 43 - agree - disagree - follow up
  • + Re-written and stable CDFS and support.
  • + There seem to be a lot of strange problems caused by CDFS, many nothing to do with CD access!
  • + How about supplying CDFS 3 that Acorn have already written, and writing a backend to make it talk to old drivers? Writing such a backend isn't a very hard job...
  • - spawn of the devil and Maggy Thatcher.
  • - I assume that previous comment refers to CDFS 3.
• Mac OS discs (2013-08-06) - 33 - agree - disagree - follow up
  • + Read/Write MacOS discs
  • - MacFS seems to have worked brilliantly for a VERY LONG TIME! (Thanks John!)
• DVD Support (2013-07-09) - 30 - agree - disagree - follow up
  • + Support DVD for Data and Viedos
  • + That would be nice, but I think even the StrongARM-RiscPC is not powerful enough to render DVD-videos. Is it?
  • + aren't the people who make viewfinder going to make a DVD card?
  • + If RISC OS were fully 32-bit, then the new Strong ARMs could be used and DVD processing should be possible!
• UIDs on files (2013-07-09) - 26 - agree - disagree - follow up
  • + Like on unix systems - it would be nice if each file on the system had an owner, and the public access bits actually did something on a local machine...
  • + Why not just have a networked server, and let the server decide user access permissions...
  • - To be honest, as a single user I generally find UNIX user permissions a pain. RISC OS is really only a single user machine and is considerably harder to completely screw up by accidently deleting the wrong file. If you want user security, use a server.
  • + With RISC OS Adjust it is multi-user So why not? Security IS a problem for most UNIX / Windowz users in RISC OS.
• Mount Reinier (2013-07-09) - 22 - agree - disagree - follow up
  • + cd-rw function within os
  • + of course that *should* read mount rainier
• journaling file system (2013-05-15) - 18 - agree - disagree - follow up
• File/Directory Hiding (or Security) (2013-07-09) - 17 - agree - disagree - follow up
  • + Allow the user to specify directories or files that require password access
  • + Why not just use a networked server, and let the server decide user access prmissions?
  • + To Hide a file simply put it inside an app and give it an obscure name nobody would search for.
  • + I don't like hiding, but would greatly appreciate things like password encryption of files or even entire directories.
  • + This should be a part of the Filer's options menu. But opening / Editing the file would create a password box
• Support for filename extensions (2013-07-22) - 13 - agree - disagree - follow up
  • + Whilst RISCOS filetypes work very well, there are often situations e.g. java,python; where extensions are needed. How about allocating a special RISCOS filetype which means, "This file has an extension instead".
  • + Hmmm. It is true that we are governed strongly by Win developments. Implimenting a recognition of DOS extensions would be very useful.
  • + The DOS filetype could be used to allow recognition of files with filetype DOS.
  • - Problem occours when you have filename.java and filename.class
  • + Optionally allow DOSmap to automatically override the filetype of RISC OS files, where they have a valid DOS/UNIX file extension. In my experience it is FAR more common for files to have a correct file extension, and wrong RISC OS file type, than the other way around.
  • + Doesn't Win95FS already do this?
• File generation numbers (2013-04-09) - 10 - agree - disagree - follow up
  • + Allow several versions of files with generation number eg. fred(1) gets edited into fred(2) etc while dlete fred(-3) would allow usual (OK mainframe) means of keeping rolling versions of father, grandfather etc
  • + How about an in-built File Version system (in a !FileVersion app in resources?). This way a new menu item "Previous Versions" Could be added!
• Security (2013-05-14) - 9 - agree - disagree - follow up
  • + Native security at file system level.
• %age progress bar (2013-08-30) - 8 - agree - disagree - follow up
  • + I copy a fair amount data from a HDD to a zip disc and I think it would be handy to have a progress bar so you have some idea how long the operation will take. Surely this would be fairly easy to implement - a quick count of the files to be copied, a few sums here and there, hey presto!
• Longer filetype names (2013-05-15) - 7 - agree - disagree - follow up
  • + 8 characters in a filetype name isn't really enough
• Filing system Database (2013-07-09) - 0 - agree - disagree - follow up
  • + Files stored and indexed according to name, type,length,date,application associated with Display tree structure, search engine
• Total security from theft (2013-07-09) - -5 - agree - disagree - follow up
  • + Here's an EXCELLENT idea for safeguarding confidential information on the hard drive... First, an optional username/password could be required to start RISC OS. When the user wants to turn off the computer, RISC OS will encrypt the entire drive QUICKLY and proceed with closing down (this is optional, but highly recommended) - this feature could be available ONLY if the user has to type their username/password to start RISC OS. If the computer is stolen, only the correct password will decrypt the drive - and start RISC OS.
  • - Wow! Just like that eh? A total hard drive encrypted? Marvellous.
• Allow same name for files of different type (2013-07-09) - -7 - agree - disagree - follow up
  • + We could move/copy in the same directory objects (files or directories) with same name but different type without overwriting anything.
  • + Ok, you work out a way for that to work and someone will no doubt implement it. RISC OS does not support that. It's like saying "Let's have five people in a house called John Smith and when a bill comes in whoever picks it up can pay it."
  • - We dont have filetype extensions in RISC OS - that's how windows tells them apart.
  • - That is right, but files nevertheless ARE filetyped, so use THAT information to tell them apart.
  • - Sometimes this would be nice, however, if wecan't used the file type info to tell different files apart - older apps wouldn't pass the necessary info about which one they wanted.
• Support for 2048 Sectors (2013-07-09) - -11 - agree - disagree - follow up
  • + Um MOD-Disketten mit 2048 Bytes pro Sector (640MB Disk) benutzen zu können.
• More File Types (2013-04-09) - -11 - agree - disagree - follow up
  • + There are not enough file types in riscos how about extending the &000-&FFF to &0000-&FFFF
  • - But there are already 4096 filetypes and they are not all used. Why do we need more?
  • - How many times have you heard "why would we need more?" in the computing world?
  • - To my knowledge, the last allocated filetype number is &188 for Flash (IIRC). Now, if I'm going to be ruthless and say that everything above &c00 is taken, then that leaves 2680 filetypes. Granted, there are a number in the middle range, but they can be considered to fit into the group above &c00 where there aren't entries. So, out of ten years development we consider that we have used about 35% of available space. With correct re-use of filetypes and no needless allocations for private types I think that there is no problem.
  • + It we get rid of load/execution addresses this wouldn't be a problem (Get 0-&fffffff), though some old apps/data formats may screw up. Introducing it before it is needed will 'encourage' programers to allow for it in their software and unless any of the new types are actually used no incompatible software will break anyway.
• Allow dropping from a file on a directory (2013-05-14) - -12 - agree - disagree - follow up
  • + When one drops a file on a directory it should be enough to place the file in that directory like on Macintoshes.
  • - No! Horrible horrible horrible. I hate having to aim accurately when using windows to ensure that a file I've dropped into a window doesn't accidently go into a subdirectory instead of the one it should be going into. Especially when it's a file I've accidently picked up and just want to drop back down harmlessly.
  • + This should be an option...by default off but the ability to turn it on! Same goes for Drive Icons on the IconBar (I know apps already do this, but why not in the OS?
• DOS disks (2013-08-30) - -448 - agree - disagree - follow up
  • + Built-in capability for long file names on Windows discs.
  • - Speak to WSS.
  • + Yes, but LET'S HAVE IT AS STANDARD!
  • - How much extra do you want to pay extra for it ?
  • + Yes, Windows long file names should be handled transparently by DOSFS. Also, you should be able to save long filenames to a DOS disc from RISC OS, in this format.
  • + Remove the bug that doesn't allow you to write more than 720k on a 1.44MB formatted disc!
• Disc repair (2013-08-30) - -7486 - agree - disagree - follow up
  • + Disc repair tool for E+ hard discs (and E+/F+ format floppies).
  • + It's being worked on.
  • + Also so it'll work on DOS discs too. It's damn annoying to get a bad sector on a dos disc and having to switch over to a pc to map it out
  • - If you get a defect on a disc, throw it away.
  • + And if you have a defect hard disk throw it away too???? No, disk repair _and_ undelete (or at least a system integrated trash bin) are MUST HAVEs...
  • - Yes. If you have a defect on your Harddisc it's probably screwed, so you'd probably be better to just get one that you know works. Defective discs are generally defective for a reason and continuing to use them only means you increase the risk that you lose more data. 'Fixing' a physically broken disc isn't even a vague solution.
  • + If your hard drive gets damaged a disk fix utility is very useful because it allows you to backup what's left before moving to a new harddrive
  • + It might not be a physically defective disk. Filesystem corruption is always a threat.
  • + Fixing Bad Sectors
• add a new item

Return to wishlist, or acornusers.org.