I just tried five or six ways to get this, but I’m a bit stumped.
I’m trying to get a list of files on removable drives - USB, CD, DVD, shared network or hard disk even.
On Linux, I’m cheating - we mount the disks as disk1-diskN, so I just looks for those.
On Mac, I get the list of files that are directories and non-hidden in /Volumes. But the root disk is in there and that’s pretty much the only one I don’t want - and I really don’t want it.
I tried comparing to T("/") - nope, it’s /Volumes etc. Can’t get the parent of / - that’s / too. Can’t get the linked folder of / etc.
Tried to compare the drive serial number and didn’t have luck either - maybe since the links on /Volumes are on the disk too?
Anyway, I really need:
isRootDisk () or a SpecialLocation:RootDisk to compare with maybe?
Hi Bruce,
You can try using this "juce bool File::isOnRemovableDrive( ) ", this method returns true for “USB, CD, DVD”(haven’t tested it for shared network).
If it returns, true get into the folder and look for the files, else skip the folder
For my money, what would be more useful is a general:
File::getAttachedVolumes() method that function similarly to File::findFileSystemRoots(), and takes an optional ignoreSystemDrive parameter. Obviously the difference being that it’ll return volumes on Linux and Mac, not just drives on windows. Moreover, it could potentially return non-mapped drives on windows too.
I was actually working up to writing something like this myself, but I’m not sure enough about evaluating attached volumes on Linux, so it’s a couple of items down on my list right now.
Do you have any scratch Mac code you started by any chance?
Linux could be tough - everyone can mount things where they want. There may be an API to get it, maybe one of those ‘proc’ systems (where there’s a folder of text files with the info).
[quote=“Bruce Wheaton”]So you couldn’t see a Juce way to do it either?
[/quote]
TBH, I haven’t tried that hard. For the bodge I needed, just enumerating /Volumes/ worked. The redundant system drive is not an issue. I have one mac user (not counting myself), and he’s happy that anyone cares. My Linux users are noisier though, so I need a full x-plat solution.
No[1]. Mostly because I tend to start with the hard problem first; in this case:
I really have no feel for what Linux does with this kind of thing. /dev obviously gives you some stuff to work with, but it doesn’t cover NFS mounts, etc. I’m not sure if it’s just the case that /etc/fstab has to be handled differently, or if, as you say, there’s some holistic proc representation of attached file systems.
I need to finish some features for a internal build of my app by the end of this week, but if you want to look at this stuff together next week, I’d be happy to have an extra set of eyes hunting clues.
[1] I went wandering into BSD land, and I can see some possible ways to get at that data, but I haven’t tried anything yet. My guess is though that the boot disk should be disk0 in the BSD world. As such, FSGetVolumeInfo or statfs should be able to identify /Volumes/OSX Disk as being disk0, and thus the boot drive.
