Support, Frequently Asked Questions

Why are PFO files larger than ZIP/CFS/RAR/7Z files with the same contents?

Is there a zero-install (or "portable") version of PFMAP?

Can you add write support to PFMAP for ZIP or ISO?

Can you add support to PFMAP for TAR or RAR?

Can you add support to PFMAP for 7Z?

Why are PFO files larger than ZIP/CFS/RAR/7Z files with the same contents?

PFO is not an archive or distribution format like ZIP, ISO, CFS, 7Z, or RAR. PFO is a full file system like NTFS, EXT2, or FAT32. Compared to archive formats, file systems have additional overhead for allocation management and fault tolerence.

PFO uses ZIP (deflate) compression. ZIP does not compress data as tightly as some other algorithms, but other algorithms are too slow for general file system use.

Is there a zero-install (or "portable") version of PFMAP?

No.

File system extending products on Windows must load kernel extensions (or drivers). Loading kernel extensions requires administrator privileges. The PFMAP installer takes care of loading the needed kernel extension, allowing PFMAP to be used from normal user accounts.

Applications that require administrator privileges to run can only be used on systems where the user knows an administrator password. This makes the applications inherently un-portable.

Applications that require administrator privileges to run become a barrier to using Windows from normal user accounts. This generally reduces system security and furthers the spread of malware.

Can you add write support to PFMAP for ZIP or ISO?

Maybe, but not in the near future.

File system write support for archive formats is not difficult, but it cannot work in an ideal or predictable way. Archive data formats are not designed to allow efficient dynamic modification. Saving modifications to archive files generally requires rewriting the entire archive. For large archives this can create a low quality user experience.

Can you add support to PFMAP for TAR or RAR?

Maybe, but not in the near future.

These archive formats do not consistently have the compression and directory indexing needed for random read access.

Support for these archive formats can be implemented by pre-extracting the archive into a temp folder or into memory. Pre-extraction can be effective for small archives, but does not work well (or at all) for large archives.

Pre-extraction provides no inherent benefit over the extraction provided by traditional archive utilities. Pre-extraction takes roughly the same time upfront as normal extraction. The user no longer has to manually delete the extracted files, but now has to manually unmount the volume. Pre-extraction still uses hard drive space, either in temp files or in the page file.

Support for these archive formats can also be implemented by pre-indexing. This is not a great solution as you end up having to read and decompress the entire archive twice for many usage scenarios.

Can you add support to PFMAP for 7Z?

Maybe, but not in the near future.

7Z would likely already be supported, except that it requires the use of compression algorithms and filters whose implementations are released with restricted licensing.