Tar archive entry.

Native FilePath of the file or directory within the archive.

The content of a tar archive entry, which depends on the type of entry.

Portable archives should contain only NormalFile and Directory.

The number of seconds since the UNIX epoch

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

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.

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.

This is a utility function, much like getDirectoryContents. 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.

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 too long. See TarPath for a description of the problem with splitting long FilePaths.

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 (eg using checkSecurity).

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. This may fail if the 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.

Convert a tar LinkTarget to a Windows FilePath.