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.
|