Linux and MacOS file system question
BlitzMax Forums/BlitzMax Programming/Linux and MacOS file system question
| ||
| Hello. I'm writing my own file requester that works in full graphics mode, but I don't own a Linux or MacOS machine, so I have some questions about how their file system is organized: - In Windows (and DOS, really), a volume can have a final root of A:, B: (if you have two floppies), C:, D: and so on. If I use ChangeDir("..") repeatedly, I will eventually end up in one of those volumes, but I can not 'cross over' to one of the others without specifying the volume itself (such as ChangeDir("C:", etc)). I don't think this is the case in Linux or MacOS, right? - So how does one switch to another drive/volume/partition/floppy without specifying a drive letter in thse two OSes? What is ther syntax? I hope my question is clear. I want the user to be able to access ANY file on their system, whether they have Windows, Linux or MacOS. On this same note: Is there a way to check for the existance of a drive, even if it's not ready. For example, If I do a FileType("A:") in Windows and there is not a disk in the drive, instead of just returning a zero, Bmax opens its own window to say that there is no disk, etc. This would not be that big a deal in GUI mode, but in full screen mode it minimizes the whole screen and then pops up the window, etc. Anyway, I seem to remember that other versions of Blitz did not do this. Thanks in advance, Russell |
| ||
| No, on OSX / Linux, the toplevel is / whereas the drives itself are withing /dev/... (their devices) and /mnt/... or /mount/... (the actual drive mounts) |
| ||
| - So how does one switch to another drive/volume/partition/floppy without specifying a drive letter in thse two OSes? One doesn't. The ammount/size and configurations of physical drives is completely transparent to the filesystem. |
| ||
| In Windows, a mounted drive is given a simplified shortcut as C, D, etc. It still is possible to mount a drive to anywhere in the filesystem (Eg: Documents And Settings could be in a different hard drive), but this behaviour is not default. With Linux (and I'll assume Mac OS), the default behaviour is not to hide the mount points for drives; they are always mounted on a particular directory within the root filesystem (which is whatever drive partition the OS was booted from). This mount point is often /media or /mount, though it could be anywhere. For example, I have my /home directory as a mount point for my secondary hard drive, so that every thing in my home folder is separate from the other data. As a result, I am not at risk of losing my data when I reinstall the operating system. I bet there is a way to figure out where a device is mounted without hunting. All devices, mounted or not, are described in /dev. So, with Linux / probably Mac OS, if your program were to recursively parse every file and directory within the root directory, it would eventually have read every file in every mounted drive because they are all mounted in plain sight. In terms of file requesters, I suggest you do not list mounted drives for shortcuts in Linux (again, I'm not sure about Mac OS). There is a Places list somewhere in most distros, which would feel more normal. Finally, just because I'm weird, I must ask one thing. Is a non-standard file requester really necessary? They tend to scare/anger people who get used to the features provided by their OS -- especially if those features are special features that are completely fresh. I understand if this is a full-screen thing, of course... though this brings up another thing which I have observed: Full-blown file browsers for simple tasks also scare people. If it is possible to require files (such as custom game levels) to be placed in a particular directory, do it and do not offer flexibility. People cower in horror when they have to search through an entire filesystem to find a file, and would rather have a very restrictive list locked to a single directory. I probably made no sense... for an example, my Nuclear Reactor Simulator uses a non-standard file explorer to load levels, but I do this for the sake of usability. I have it locked to a single levels directory and made it extremely simple, thus preventing the user from storing levels elsewhere but also keeping them from being confused by the wealth of extra options they would otherwise be offered. I'm bringing this up (even though it's probably way off topic) because I've noticed it with a few other programs. For example, I have had an IDE actually ask me - with a full-blown file explorer dialog - where I want to store my settings. That's very nice of it to ask, but why the heck would I or anyone else care?! It already has a settings file in a completely acceptable location (/home/me/.someide) that says where I told it to store my settings, so why can't it just use that? It actually did confuse me and it had me a bit worried. I thought at first that it was some kind of a puzzle; if I didn't choose the right settings directory, it wouldn't work. This turned out to not be the case (it worked) but it was quite irritating. Same happened with projects, which is a bit more sensible, but I think it should just do those sorts of things automatically; either hide the project file within the settings directory, or put it in a nice place in the location where I'm putting my source code. Why should I have to choose? Er... way off topic. Don't let that hijack this thread, please :/ Edit: Oh, full graphics mode. Oops! Good luck! |
| ||
| Someone mentions a module to retrieve volume information HERE, and a link to the site containing it HERE. Looks like it's win32/linux only for now (at least until his Mac gets fixed). |
| ||
| I bet there is a way to figure out where a device is mounted without hunting. Yes. /etc/fstab |
| ||
| On Mac, drives are mounted in the /Volumes folder. |
| ||
| Thanks. I think. :/ So I take it, as long as the user can get to the root (using changedir("..")) then all will be well in Linux/ MacOS? On Mr. Pickelsworth point(s): I basically agree with the idea of 'forcing' the user to have their levels (or whatever the case may be) in one location, and I almost did just that. But I leaned towards flexibilty in this one case and decided to make it a full-blown file browser instead (which took 100 times longer than I expected - Ended up having to write my own sort routine because array.Sort doesn't seem to work with arrays of User Defined Types. That is, there doesn't seem to be a way to specify what Field I want to sort by, etc.). Anyway, everything works beautifully, I must say, although sorting the Windows/System32 directory takes over 20 seconds (There are 2047 files and directories in there). I know the bottleneck is the fact that I am physically swapping the data from object to object. I may try to do it with pointer sawpping, but I don't know if I have the smarts yet.... Thanks again, Russell |
   |