snb90@uk.ac.soton.ecs (Stewart Brodie) (03/14/91)
Question for Acorn: Would it be possible to have 'Disc Free Space' (or just 'Free' even) on the Filer menu rather than leave it to the individual filers to provide a free space utility? This would mean that I could examine the free space on a disc without having to search the icon bar for the correct filer icon. Stewart Brodie (snb90@uk.ac.soton.ecs)
Julian.Wright@comp.vuw.ac.nz (John Julian Wright) (03/19/91)
In article <7151@ecs.soton.ac.uk>, snb90@uk.ac.soton.ecs (Stewart Brodie) writes: |> Would it be possible to have 'Disc Free Space' (or just 'Free' |> even) |> on the Filer menu rather than leave it to the individual filers to |> provide a free space utility? I think the problem there is that there is currently no call (that I am aware of) that accepts as a parameter a pathname and returns the free space remaining for that path, that works for all existing and future filing systems. The existing calls to determine free space require that the application either: 1) Know the filing system's private word, in order to call FileCore_FreeSpace or 2) Know the filing system's SWI prefix, in order to call FSPrefix_FreeSpace, which in turn calls FileCore_FreeSpace. (1) is plainly undesirable. (2) is clumsy, as there is no way of knowing what the SWI prefix for a new, as-yet-unwritten FS is. VKiller suffered from this problem a while ago when guessing the prefix for SCSIFS and getting it wrong :-( It IS possible to _display_ the free space for a given path... you extract the FS name from the path (eg. "adfs:") and put it in front of a call to 'free' ie *adfs:free :0 but this is of little use to programs which want to place the free space in a numeric variable... I have searched the PRMs for the appropriate call but as yet without success, which leads me to believe that it doesn't yet exist. If it does, somebody please tell me about it... Cheers, Julian.
snb90@ecs.soton.ac.uk (Brodie SN) (03/22/91)
Julian.Wright@comp.vuw.ac.nz (John Julian Wright) writes: > 2) Know the filing system's SWI prefix, in order to call FSPrefix_FreeSpace, > which in turn calls FileCore_FreeSpace. > (2) is clumsy, as there is no way of knowing the SWI prefix for a new, > as-yet-unwritten FS is. VKiller suffered from this problem a while ago > when guessing the prefix for SCSIFS and getting it wrong! THERE IS A WAY!!! (but it's a cludj) Make a text file for the application containing all the SWI prefixs known at time of writing. The user can update the list when new filing systems are brought out. However, the clever bit is then using the OS_ConvertSWINumberFromName or whatever it is with FSPrefix_0 as the name. If this call succeeds, you know that that particular FS is present, and can do processing on it! Not a great solution really, but it can get round the problem a bit. ** Stewart Brodie (snb90@uk.ac.soton.ecs)
Julian.Wright@comp.vuw.ac.nz (John Julian Wright) (03/25/91)
In article <7284@ecs.soton.ac.uk>, snb90@ecs.soton.ac.uk (Brodie SN) writes: |> Make a text file for the application containing all the SWI prefixs |> known at time of writing. The user can update the list when new filing |> systems are brought out. Ouch! Call me paranoid but if there is one thing I don't want to get the end user to get involved in it's a list of SWI prefixes... |> However, the clever bit is then using the OS_ConvertSWINumberFromName or |> whatever it is with FSPrefix_0 as the name. If this call succeeds, you know |> that that particular FS is present, and can do processing on it! This can only verify that the SWI prefix list contains valid entries... there is nothing the program can do if one of them turns out to be invalid. An alternative is to: 1) Scan for new filing systems by number 2) Convert the filing system number into it's name, when one is found. 3) Scan all modules for a title which contains the filing system name. Hopefully there will be only one (fat chance! - look at econet...) 4) For all modules found, rummage around until you find their SWI table 5) Convert all SWIs found this way into strings. 6) Search the strings for "FreeSpace" but even this fails to provide a way of returning the free space from a path variable, which is how we are supposed to refer to all filing systems anyway. I suppose I could eliminate the first three steps in the above and just scan ALL current modules for SWIs containing "FreeSpace", but this sort of thing takes time... and you get problems when using "temporary" filing systems like RAMFS which might not have been around when you scanned the modules but has been added later. Cheers, Julian -- ;`````````````````````````````````````````````````````````````````````````````; ; I would if I could but I can't so I won't but I might if I find I can later ; ;,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,; jwright@comp.vuw.ac.nz julian@sideways.gen.ac.nz