Filetype handling in detail
This is an extension of a previous article where I discussed filename handling on foreign systems and in particular, how RISC OS filetypes ought to be represented on systems which do not no nominally support them.
This last point is still a matter of confusion for some people. This has been compounded by bugs in some filesystems which do not implement the system I described properly, and also by misinformation that has been given in certain instances. In this item, I will try and enumerate all the RISC OS filesystems and programs that deal with the issue of handling RISC OS filetypes and document how well they perform. I will stress that some of this information is from memory as I do not have immediate access to all of them, but I have checked where possible. I would appreciate any corrections or additons.
SunFish - This implements all aspects of the system fully. One thing it can't always do, and this is because of NFS itself rather than SunFish is follow symlinks as they may point to outside the mount.
LanMan98 - This also implements the system correctly. I strongly recommend you do not use its "notypes" option. In some instances this may appear to work more correctly than without, but what's really happening is that it's masking issues. notypes won't allow you to change filetype and it can display ,xxx extensions at the RISC OS end which is almost never useful.
LanManFS - This is mainly in reference to the version bundled with RISC OS 5. I don't believe that LanManFS always gets the filetyping right. Sometimes it appends the ,xxx when it shouldn't be. In addition, it has a fixed buffer size meaning it might not display all the files in a large directory. I've also seen it have issues with certain filename characters causing confusion. I recommend using LanMan98 or SunFish instead if you can.
HostFS (VirtualRPC) - HostFS has two options for filetype handling, neither of which are particularly satisfactory. One option always adds the ,xxx and other acts like "notypes" in LanMan98. Its default filetype is also incorrectly set to data rather than text. If you're only looking at files you've created from within VirtualRPC, then the first option will work ok, but once you start accessing files transferred onto the host system or created there, then you can quickly run into problems. Note that HostFS is also used for VRPC's CD access.
ImageNFS - I don't have access to this, but I understand it behaves correctly.
DOSFS/Win95FS - To the best of my knowledge, none of these understands the ,xxx system. However, they can make use of a free FAT field to store the RISC OS filetype if it's changed on RISC OS. This generally works just fine.
CDFS/CDROMFS - Again, these do not make use of the ,xxx extension (except when viewed by a remote system which does like NFS), but there is an extension to the CD format which can store the RISC OS filetype. Usually, however this is not used as the mime mapping from the extension is sufficient for CDs, or RISC OS files are put in zip files on the CD.
SparkFS/Zip files - The zip format too contains an extension to contain the RISC OS filetype if it's set. SparkFS itself does not make use of the ,xxx extension, although I don't know if any of the other RISC OS zip extractors do. The single change I make to my SparkFS setup is to make the default type text rather than data. This is because of reasons I outlined in the article above, and can make somethings work more smoothly. For creating zip files on a foreign system, GCCSDK contains a modified version of InfoZip which can optionally turn the ,xxx extension on (for example) the Unix filesystem into the filetype in the extra zip field, and strip it from the filename. There is one potential ambiguity however - filenames which have more than fullstop in them (i.e, a Unix/DOS extension) and with no ,xxx extension get an explict RISC OS textual type for consistency.
UnixLib programs - most UnixLib programs don't have any need to make use of this system, although there are some exceptions such as John Tytgat's port of CVS. We made very sure that UnixLib implements all aspects properly where relevant, since getting filename handling correct can be crucial with Unix ports.
Linux ADFS - When mounting an ADFS filesystem under Linux, the RISC OS filetypes are ignored. However, I did make a modification which allows the ,xxx extensions to be concatenated where appropriate. This can be handy when viewing the exported filesystem on a real RISC OS system. This change should be usable in the Iyonix Linux kernels.
Messenger/Pluto - For attachments, these mailers will need to make to make a mime match back and forth. I don't have Pluto, nor the latest version of Messenger, but I believe that in most instances they do it ok, but the default filetype is not text, which may cause issues.
This last point is still a matter of confusion for some people. This has been compounded by bugs in some filesystems which do not implement the system I described properly, and also by misinformation that has been given in certain instances. In this item, I will try and enumerate all the RISC OS filesystems and programs that deal with the issue of handling RISC OS filetypes and document how well they perform. I will stress that some of this information is from memory as I do not have immediate access to all of them, but I have checked where possible. I would appreciate any corrections or additons.
The Filesystems
AcornNFS - I don't have access to this so can't comment on its implementation, but I understand it is the only RISC OS filesystem that implements a method of representing untyped files with an extension to the ,xxx system. Normally, this feature isn't used in modern RISC OS usage, as untyped files are quite rare and not that useful, and I don't judge its loss in other implementations as a failure, but it might be useful in some instances.SunFish - This implements all aspects of the system fully. One thing it can't always do, and this is because of NFS itself rather than SunFish is follow symlinks as they may point to outside the mount.
LanMan98 - This also implements the system correctly. I strongly recommend you do not use its "notypes" option. In some instances this may appear to work more correctly than without, but what's really happening is that it's masking issues. notypes won't allow you to change filetype and it can display ,xxx extensions at the RISC OS end which is almost never useful.
LanManFS - This is mainly in reference to the version bundled with RISC OS 5. I don't believe that LanManFS always gets the filetyping right. Sometimes it appends the ,xxx when it shouldn't be. In addition, it has a fixed buffer size meaning it might not display all the files in a large directory. I've also seen it have issues with certain filename characters causing confusion. I recommend using LanMan98 or SunFish instead if you can.
HostFS (VirtualRPC) - HostFS has two options for filetype handling, neither of which are particularly satisfactory. One option always adds the ,xxx and other acts like "notypes" in LanMan98. Its default filetype is also incorrectly set to data rather than text. If you're only looking at files you've created from within VirtualRPC, then the first option will work ok, but once you start accessing files transferred onto the host system or created there, then you can quickly run into problems. Note that HostFS is also used for VRPC's CD access.
ImageNFS - I don't have access to this, but I understand it behaves correctly.
DOSFS/Win95FS - To the best of my knowledge, none of these understands the ,xxx system. However, they can make use of a free FAT field to store the RISC OS filetype if it's changed on RISC OS. This generally works just fine.
CDFS/CDROMFS - Again, these do not make use of the ,xxx extension (except when viewed by a remote system which does like NFS), but there is an extension to the CD format which can store the RISC OS filetype. Usually, however this is not used as the mime mapping from the extension is sufficient for CDs, or RISC OS files are put in zip files on the CD.
SparkFS/Zip files - The zip format too contains an extension to contain the RISC OS filetype if it's set. SparkFS itself does not make use of the ,xxx extension, although I don't know if any of the other RISC OS zip extractors do. The single change I make to my SparkFS setup is to make the default type text rather than data. This is because of reasons I outlined in the article above, and can make somethings work more smoothly. For creating zip files on a foreign system, GCCSDK contains a modified version of InfoZip which can optionally turn the ,xxx extension on (for example) the Unix filesystem into the filetype in the extra zip field, and strip it from the filename. There is one potential ambiguity however - filenames which have more than fullstop in them (i.e, a Unix/DOS extension) and with no ,xxx extension get an explict RISC OS textual type for consistency.
UnixLib programs - most UnixLib programs don't have any need to make use of this system, although there are some exceptions such as John Tytgat's port of CVS. We made very sure that UnixLib implements all aspects properly where relevant, since getting filename handling correct can be crucial with Unix ports.
Linux ADFS - When mounting an ADFS filesystem under Linux, the RISC OS filetypes are ignored. However, I did make a modification which allows the ,xxx extensions to be concatenated where appropriate. This can be handy when viewing the exported filesystem on a real RISC OS system. This change should be usable in the Iyonix Linux kernels.
Messenger/Pluto - For attachments, these mailers will need to make to make a mime match back and forth. I don't have Pluto, nor the latest version of Messenger, but I believe that in most instances they do it ok, but the default filetype is not text, which may cause issues.
(Comment this)
When making comments here, please don't hide behind aliases, or I may simply remove your comment. (Comment this)