A filesystem module implements similiar callbacks as the Linux Kernel filesystem. It isn't needed to implement both the importing and exporting functions. It is possible to write just importing filesystem module (but these filesystems would be able just to convert themselves to some other filesystem).
The importing callback functions don't read the real file data (Partition Surprise doesn't care on them), but it returns the logical position of the data blocks. All the file data blocks are stored in extents which consist of the position and the length (to optimalize the space occupied by unfragmented files). Directory reading functions convert filenames into Unicode UCS4, fill all the inode attributes (access rights, ownership, total file size,...).
When checking about the possibility of doing the conversion the imported filesystem is responsible for counting the total file size considering all possible target block-sizes. The file size is rounded up to the block-size of the target filesystem, so it is possible that a filesystem consisting of many small files will be unable to convert into another one.
The exporting callbacks do not need to implement the whole write access, only creating of a new file/directory and appending the data blocks is needed. When appending the data blocks, GConv advices the filesystem where to allocate the data block (it equals the original file position in the imported filesystem). If that position is inaccessible for some reason (another alignment, already allocated by another data etc.), any other position may be used. When creating a new file/directory, some metadata is usually allocated. GConv advises the filesystem which free blocks should it use (the same blocks that were free in imported filesystem) to prevent the filesystem from allocating the empty blocks before the files stored in that places are moved. If the allocation in recommended free blocks is from some reason impossible, nothing really matters, because the files originally stored in allocated position will be moved (and the conversion will be somewhat slower).
Filesystem creates target inodes according to the GConv inode structure and converts a filename given in UCS4 into target codepage. A special callback is called at the end of the conversion to allow to flush the caches and close the data structures of the filesystem.
The following filesystems are supported: