@ChrisH Check out the OS3 DOS Info() function. Look at the OS3 DOS InfoData structure and you will see that the filesystem type is encoded as hexadecimal. According to OS4 DOS autodoc, Info() only gets the filesystem if there is a disk inserted.
You can also look at the source for the Dopus5 diskinfo module. The file diskinfo.strings contains the definitions for a lot of filesystems and the diskinfo_info() function in diskinfo.c shows how Dopus5 gets the filesystem type.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
@all Thanks for all the suggestions, but sadly none of them actually do what I'd wanted (at least not reliably), which is to identify SMBFS (and maybe FTP Mount) volumes :
FindDosEntry()->dol_misc.dol_device.dol_Handler identified the FTP Mount handler, but is no use identifying SMBFS (NULL bcpl string for Device mode), and of course no use at all for normal Volumes like SFS (or SMBFS in Volume mode).
FindDosEntry()->dol_misc.dol_volume.dol_DOSType is no use for the FTP Mount handler (it's not a Device), while for SMBFS (in Volume mode) it uselessly reports the type as DOS\0. Of course it works fine for normal Volumes like SFS.
Info(lock, infodata) ; infodata->id_DiskType is not really any different to dol_DOSType above, except that for SMBFS (in Device mode) it uselessly reports DOS\0.
GetDiskFileSystemData() reports nothing for SMBFS & FTP Mount. For normal Volumes like SFS it does work, but the data provided is of no use for my purposes: fsd_DeviceName is something like "sb600sata.device", while fsd_FileSystemName is something like "HDD2:".
Examining the code of DOpus5's diskinfo module is not likely to be any use, since that presumably only works on normal Volumes visible from Workbench.
edit: Corrected the FindDosEntry() pseudo-code to be more like C.
What about examining the code for dopus5's device list? that at least detects SMBFS correctly
How do you mean "detects ... correctly"? What info does it provide for SMBFS? Bearing in mind that the user can give the SMBFS volume/device any name they wish...
@ChrisH I don't think you can get what you want from a simulated filesystem like FTPMount or SMBFS. The actual filesystem is located at other end of a network connection. FTPMount stopped working for me with OS4.1FE so I updated my personal copy to work with FE and have been slowly updating it further. FTPMount simulates a media device with the device name FTP: and a volume name of FTPMount. FTPMount identifies itself as DOS/0 but the files could be coming from any filesystem where the connected server is located on. The FTPMount hosts directory is what's displayed as FTP: when you enter "dir FTP:" and uses the filesystem where the FTPMount directory is located. When you access an FTP site, FTPMount is obtaining the files/dirs from the connected FTP server which could have a Unix, Windows, Linux or other filesystem. FTPMount is just tricking AmigaDOS into interacting with it as though it were an Amiga filesystem. In fact FTPMount can be connected to several FTPServers at once but present them to AmigaDOS as a single Amiga filesystem.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
@xenic I don't care what filesystem is used at the other end, just whether or not SMBFS or FTP Mount are being used at all. I could have imagined a fake dos type "FTP/0" or similar being specified, since this would make marginally more sense than "DOS/0" (which is an outright lie, and could lead to software expecting specific FFS behaviour that is unlikely to be emulated).
Quote:
I don't think you can get what you want from a simulated filesystem like FTPMount or SMBFS.
I *can* for FTP Mount, since it's handler is given as "L/FTPMount-Handler" (as expected). But SMBFS's stated handler is a NULL bcpl string :( , which seems a bit buggy (I'd argue it should at least be an empty string, and possibly a fake handler name).
Unfortunately it was SMBFS I was really interested in detecting, because I can already detect FTP Mount by the fact that it has a root device of FTP:, etc.
@xenic I don't care what filesystem is used at the other end, just whether or not SMBFS or FTP Mount are being used at all. I could have imagined a fake dos type "FTP/0" or similar being specified, since this would make marginally more sense than "DOS/0" (which is an outright lie, and could lead to software expecting specific FFS behaviour that is unlikely to be emulated).
I'd say that specifying the DOSType as DOS\0 is a bug and it should be FTP\0 or SMB\0 in the examples given. Basically anything not being used is fine, built-in types should definitely be avoided as certain assumptions may be made (eg. DOS\0 may make software assume 32 char max filenames for example)
Quote:
I *can* for FTP Mount, since it's handler is given as "L/FTPMount-Handler" (as expected). But SMBFS's stated handler is a NULL bcpl string :( , which seems a bit buggy (I'd argue it should at least be an empty string, and possibly a fake handler name).
I suspect that's correct. The handler name is filled in by DOS when it is mounted. smbfs runs as a command though, so doesn't have a mountlist and is constructed in memory. Anything other than NULL could cause problems as ramlib loads the path referenced when SegList is 0 (not sure that's relevant particularly, but ramlib could potentially try to open a NULL string, or a virus if a fake path has been inserted)
Quote:
Unfortunately it was SMBFS I was really interested in detecting, because I can already detect FTP Mount by the fact that it has a root device of FTP:, etc.
Unless the device has been renamed, in which case it won't...
I think DOSType is probably the correct route for smbfs, I suggest you raise a bug report with Olaf and ask for it to be set to something sensible (like SMB\0 or NTFS - NTFS is the filesystem Samba usually identifies itself as for compatiblity. There's a potential clash with local NTFS drives, but it should support the same features whether local or remote so probably OK?)
@ChrisH O.K. I just took a quick look at the sources for the latest SMBFS release and it's not mounted in the usual mountfile method like FTPMount. It looks like the user can specify a device name and volume name so you can't rely on that for an ID. Maybe the current maintainer of SMBFS can help you with identifying it.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
I can't log in to my sf.net account atm so can't comment directly there. (oh, I remember now, the passwords have to be at least ten chars long, so I set it to something ridiculous)
Doh, you are right. You could still use 'smb\0' or 'smbf' or even 'ntfs' (assuming you wanted to use lowercase as a convention for 'virtual' filingsystems).
For SMBFS you could check if dol_Task points to a proper MsgPort whose mp_SigTask points to a Process with pr_CLI set and cli_CommandName beginning with "smbfs".
For SMBFS you could check if dol_Task points to a proper MsgPort whose mp_SigTask points to a Process with pr_CLI set and cli_CommandName beginning with "smbfs".
Unless the user has renamed the program like I frequently do
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
Another alternative would be to get the process pointer from the handler's msgport (mp_SigTask), use IDOS->GetProcSegList() to get a pointer to the seglist and then use IDOS->GetSegListInfo() to scan for the version string, which should contain "smbfs" even if the program was renamed by the user.
For AmigaOS < 4.0 where the above functions don't exist you will have to read the seglist pointer directly from the process structure and then scan it for the version string manually.
Another alternative would be to get the process pointer from the handler's msgport (mp_SigTask), use IDOS->GetProcSegList() to get a pointer to the seglist and then use IDOS->GetSegListInfo() to scan for the version string, which should contain "smbfs" even if the program was renamed by the user.
I've tried that, but GSLI_VersionString doesn't seem to find anything. I assume I'm doing something wrong, but can't work-out what yet...
Am I right to take the "doslist" obtained with FindDosEntry(), and do the following?: Quote:
process = (struct Process*) doslist->dol_Port->mp_SigTask;
GetProcSegList() does seem to find & return a seglist from this... But maybe not for the right thing?
For SMBFS you could check if dol_Task points to a proper MsgPort whose mp_SigTask points to a Process with pr_CLI set and cli_CommandName beginning with "smbfs".
OS4 has renamed "dol_Task" to the (more sensible) "dol_Port". Unfortunately the "pr_CLI" seems to be nonsense (I know it's a BCPL pointer).
Given I didn't have much better luck with Salass00's suggestion either (no crash but nothing useful), I'm beginning to wonder if treating "mp_SigTask" as a struct Process pointer is wrong.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
