Polymorphic tar archive entry. High-level interfaces commonly work with GenEntry FilePath FilePath, while low-level ones use GenEntry TarPath LinkTarget.

Since: 0.6.0.0

Monomorphic tar archive entry, ready for serialization / deserialization.

Low-level function to get a native FilePath of the file or directory within the archive, not accounting for long names. It's likely that you want to apply decodeLongNames and use entryTarPath afterwards instead of entryPath.

Polymorphic content of a tar archive entry. High-level interfaces commonly work with GenEntryContent FilePath, while low-level ones use GenEntryContent LinkTarget.

Portable archives should contain only NormalFile and Directory.

Since: 0.6.0.0

Monomorphic content of a tar archive entry, ready for serialization / deserialization.

Ownership information for GenEntry.

File size in bytes.

Permissions information for GenEntry.

The number of seconds since the UNIX epoch.

Major device number.

Minor device number.

User-defined tar format expansion.

There have been a number of extensions to the tar file format over the years. They all share the basic entry fields and put more meta-data in different extended headers.

An entry with all default values except for the file name and type. It uses the portable USTAR/POSIX format (see UstarFormat).

You can use this as a basis and override specific fields, eg:

(emptyEntry name HardLink) { linkTarget = target }

A tar entry for a file.

Entry fields such as file permissions and ownership have default values.

You can use this as a basis and override specific fields. For example if you need an executable file you could use:

(fileEntry name content) { fileMode = executableFileMode }

A tar entry for a directory.

Entry fields such as file permissions and ownership have default values.

GNU extension to store a filepath too long to fit into entryTarPath as OtherEntryType 'L' with the full filepath as entryContent. The next entry must contain the actual data with truncated entryTarPath.

See What exactly is the GNU tar ..@LongLink "trick"?

Since: 0.6.0.0

GNU extension to store a link target too long to fit into entryTarPath as OtherEntryType 'K' with the full filepath as entryContent. The next entry must contain the actual data with truncated entryTarPath.

Since: 0.6.0.0

rw-r--r-- for normal files

rwxr-xr-x for executable files

rwxr-xr-x for directories

Construct a tar entry based on a local file.

This sets the entry size, the data contained in the file and the file's modification time. If the file is executable then that information is also preserved. File ownership and detailed permissions are not preserved.

• The file contents is read lazily.

Construct a tar entry based on a local directory (but not its contents).

The only attribute of the directory that is used is its modification time. Directory ownership and detailed permissions are not preserved.

Construct a tar entry based on a local symlink.

This automatically checks symlink safety via checkEntrySecurity.

Since: 0.6.0.0

This is a utility function, much like listDirectory. The difference is that it includes the contents of subdirectories.

The paths returned are all relative to the top directory. Directory paths are distinguishable by having a trailing path separator (see hasTrailingPathSeparator).

All directories are listed before the files that they contain. Amongst the contents of a directory, subdirectories are listed after normal files. The overall result is that files within a directory will be together in a single contiguous group. This tends to improve file layout and IO performance when creating or extracting tar archives.

• This function returns results lazily. Subdirectories are not scanned until the files entries in the parent directory have been consumed. If the source directory structure changes before the result is used in full, the behaviour is undefined.

The classic tar format allowed just 100 characters for the file name. The USTAR format extended this with an extra 155 characters, however it uses a complex method of splitting the name between the two sections.

Instead of just putting any overflow into the extended area, it uses the extended area as a prefix. The aggravating insane bit however is that the prefix (if any) must only contain a directory prefix. That is the split between the two areas must be on a directory separator boundary. So there is no simple calculation to work out if a file name is too long. Instead we have to try to find a valid split that makes the name fit in the two areas.

The rationale presumably was to make it a bit more compatible with old tar programs that only understand the classic format. A classic tar would be able to extract the file name and possibly some dir prefix, but not the full dir prefix. So the files would end up in the wrong place, but that's probably better than ending up with the wrong names too.

So it's understandable but rather annoying.

• Tar paths use Posix format (ie '/' directory separators), irrespective of the local path conventions.
• The directory separator between the prefix and name is not stored.

Convert a native FilePath to a TarPath.

The conversion may fail if the FilePath is empty or too long.

Convert a TarPath to a native FilePath.

The native FilePath will use the native directory separator but it is not otherwise checked for validity or sanity. In particular:

• The tar path may be invalid as a native path, eg the file name "nul" is not valid on Windows.
• The tar path may be an absolute path or may contain ".." components. For security reasons this should not usually be allowed, but it is your responsibility to check for these conditions (e.g., using checkEntrySecurity).

Convert a TarPath to a Unix/Posix FilePath.

The difference compared to fromTarPath is that it always returns a Unix style path irrespective of the current operating system.

This is useful to check how a TarPath would be interpreted on a specific operating system, eg to perform portability checks.

Convert a TarPath to a Windows FilePath.

The only difference compared to fromTarPath is that it always returns a Windows style path irrespective of the current operating system.

This is useful to check how a TarPath would be interpreted on a specific operating system, eg to perform portability checks.

The tar format allows just 100 ASCII characters for the SymbolicLink and HardLink entry types.

Convert a native FilePath to a tar LinkTarget. string is longer than 100 characters or if it contains non-portable characters.

Convert a tar LinkTarget to a native FilePath.

Convert a tar LinkTarget to a Unix/POSIX FilePath ('/' path separators).

Convert a tar LinkTarget to a Windows FilePath ('\\' path separators).