Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000886 [1003.1(2013)/Issue7+TC1] Shell and Utilities Objection Clarification Requested 2014-10-30 13:02 2019-06-10 08:54
Reporter geoffclare View Status public  
Assigned To
Priority normal Resolution Accepted  
Status Closed  
Name Geoff Clare
Organization The Open Group
User Reference
Section pax
Page Number 3052
Line Number 101525
Interp Status ---
Final Accepted Text
Summary 0000886: pax's handling of sockets
Description In the pax EXTENDED DESCRIPTION section it states as part of the description of ustar format, "Attempts to archive a socket using ustar interchange format shall produce a diagnostic message."

It is unclear whether this requirement also applies to pax format. The standard says that for pax format "The physical layout of the archive shall be identical to the ustar format", implying that only ustar requirements relating to physical layout apply to pax format - and the above statement about sockets is a requirement on the behaviour of the pax utility, it is not about the physical layout. This would seem to imply that pax is allowed to archive sockets when -x pax is used. An implementation which does this would need to use a non-standard keyword in an extended header.

Making support of sockets optional for pax format would be consistent with the way they are handled for cpio format: "Directories, FIFOs, symbolic links, and regular files shall be supported [...]. Additional file types may be
supported; however, such files should not be written to archives intended to be
transported to other systems."

There is a separate issue with copy mode and sockets. If an implementation doesn't support archiving sockets in pax format (when -w is used without -r), could it still support copying them when -rw is used? The current text would not allow this because it says "The effect of the copy shall be as if the copied files were written to a pax format archive file and then subsequently extracted" (with an exception about hard links).
Desired Action On Page: 3052 Line: 101525 Section: pax

In the EXTENDED DESCRIPTION section, change from:

Attempts to archive a socket using ustar interchange format shall produce a diagnostic message.

to:

Attempts to archive a socket shall produce a diagnostic message when ustar interchange format is used, but may be allowed when pax interchange format is used.

On Page: 3032 Line: 100678 Section: pax

In the DESCRIPTION section, change from:

except that there may be hard links between the original and the copied files.

to:

except that copying of sockets may be supported even if archiving them in write mode is not supported, and that there may be hard links between the original and the copied files.
Tags tc2-2008
Attached Files

- Relationships

-  Notes
(0002433)
joerg (reporter)
2014-11-06 17:49

There are currently no definitions for extended file types in the standard for the extended tar format that is used for pax.

star implements such enhancements and thus is able to archive sockets, but this needs a "vendor unique" SCHILY.filetype extension.

If we like to make the proposed changes, we shuld either make clear that the standard does not describe a mewthod to archive sockets or standardize a non-vendor unique variant of the SCHILY.filetype extension.

See: http://cdrtools.sourceforge.net/private/man/star/star.4.html [^]
(0002434)
philip-guenther (reporter)
2014-11-06 20:54

Can someone explain the point of this? The unarchived socket cannot be used as such and just serves to occupy the filename on disk, right?

(The thought that comes to mind is that if some software needs a dead socket to exist, then that software is Doing It Wrong.)
(0002435)
joerg (reporter)
2014-11-07 09:58

Star supports to archive any file type on the filesystem because it supports
true incremental dumps. If you like to extract incremental dumps, you need to
aware of all files on the system while trying to analyse the tiles that might
have been renamed or removed since the last incremental.

- Issue History
Date Modified Username Field Change
2014-10-30 13:02 geoffclare New Issue
2014-10-30 13:02 geoffclare Name => Geoff Clare
2014-10-30 13:02 geoffclare Organization => The Open Group
2014-10-30 13:02 geoffclare Section => pax
2014-10-30 13:02 geoffclare Page Number => 3052
2014-10-30 13:02 geoffclare Line Number => 101525
2014-10-30 13:02 geoffclare Interp Status => ---
2014-11-06 17:49 joerg Note Added: 0002433
2014-11-06 20:54 philip-guenther Note Added: 0002434
2014-11-07 09:58 joerg Note Added: 0002435
2014-11-20 17:31 Don Cragun Status New => Resolved
2014-11-20 17:31 Don Cragun Resolution Open => Accepted
2014-11-20 17:31 Don Cragun Tag Attached: tc2-2008
2019-06-10 08:54 agadmin Status Resolved => Closed


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker