Anonymous | Login | 2024-03-28 13:47 UTC |
Main | My View | View Issues | Change Log | Docs |
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 | |||||||
|
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. |
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |