 Relationships |
|||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||
| Anonymous | Login | 2024-12-02 08:21 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 | ||
| 0000291 | [1003.1(2008)/Issue 7] Base Definitions and Headers | Objection | Error | 2010-07-22 18:19 | 2013-04-16 13:06 | ||
| Reporter | eblake | View Status | public | ||||
| Assigned To | ajosey | ||||||
| Priority | normal | Resolution | Accepted As Marked | ||||
| Status | Closed | ||||||
| Name | Eric Blake | ||||||
| Organization | Red Hat | ||||||
| User Reference | ebb.filename | ||||||
| Section | 3.170 | ||||||
| Page Number | 60 | ||||||
| Line Number | 1782 | ||||||
| Interp Status | Approved | ||||||
| Final Accepted Text | See Note: 0000523 | ||||||
| Summary | 0000291: filenames need not contain characters | ||||||
| Description |
The standard states that a filename consists of bytes, then proceeds to prohibit the <slash> character from occurring in the name; it also states that a pathname consists of characters. This wording is inconsistent, given historical practice that filenames need not contain valid characters in all locales. It also has another problem with ambiguity across locales: The <slash> character is required to occupy a single byte (XBD 6.1 line 3590), but the standard currently allows a weirdnix single-shift encoding where the same byte used to encode <slash> could occur as part of a multi-byte character (XBD 6.2 line 3601 - only NUL is currently required to not occur in a multi-byte character in a stateful encoding; note that only the POSIX locale is required to be stateless [such as UTF-8] where no character is a subset of another). However, filesystems are encoding-agnostic, and filename processing should not behave differently depending on whether the current locale is stateful and has an encoding where the same byte used for <slash> can also form part of a valid multi-byte character. It is also interesting to note that ASCII and EBCDIC contain different encodings for both <slash> and <period>. The standard already states "If the encoded values associated with each member of the portable character set are not invariant across all locales supported by the implementation, if an application accesses any pair of locales where the character encodings differ, or accesses data from an application running in a locale which has different encodings from the application’s current locale, the results are unspecified" (XBD 6.1, line 3582). Are there any implementations that (want to) support both ASCII and EBCDIC encodings (or, put another way, is the intent of the standard to allow such a weirdnix system)? If so, the current state of the standard implies that all pathnames are unspecified on such a system, since <slash> and dot-dot are an integral part of interacting with the filesystem. However, this aardvark does not attempt to require having an invariant encoding for <slash> or <period> across all locales. Fortunately, restricting <slash> and <period> to not occur in multi-byte characters appears to be portable in common practice - UTF-8, Big5, and Shift-JIS all follow this convention (although the latter two do not follow the same convention for other characters, like <A>, that are also in the portable filename set), and while EBCDIC's encodings of <slash> and <period> fall within the range of multi-byte sequences permitted in Big5 and Shift-JIS, I don't know of any common attempt to mix these two encodings in a single system (that is, a system that uses EBCDIC encoding for the POSIX locale is unlikely to support multi-byte encodings except maybe UTF-8). For now, this aardvark focuses on XBD while looking for easy fixes elsewhere (namely, those mentioning <slash> in the context of filenames), so I probably missed some additional changes needed to make the entire standard consistent on referring to filenames/pathnames with the well-defined term "string" rather than the well-defined "character string" (for example, I did not touch fnmatch). Likewise, there were several spots that I did not touch in XCU, since sh(1) is required to operate on text files (modulo line length - XCU line 105252) - so we already have the bigger problem that shell scripting does not have a way to specify filenames that contain non-characters in the current locale as arguments to other utilities. The proposed changes introduce the term "slash byte" to be used instead of "<slash> character", in contexts where bytes are being discussed (similar to the existing "null byte" vs. "NUL" definitions), as well as "dot byte" (although we may decide to use "<slash>" or "<slash> byte" rather than "slash byte", for readability). There are also some existing instances of "<slash>" rather than "<slash> character", where I think it is obvious from context whether byte or character was intended. The proposed changes are slightly rearranged from sequential order, to make conceptual review easier. |
||||||
| Desired Action |
At line 1653, insert a new section before 3.139 Double-quote character: 3.139 Dot byte The byte value that encodes the <period> character ('.') in the POSIX locale. At line 2466, insert a new section before 3.347 Slash character: 3.347 Slash byte The byte value that encodes the <slash> character ('/') in the POSIX locale. Renumber the definition section accordingly (the rest of this aardvark refers to existing numbering). At line 3619 (XBD 6.2, Character Encoding), add a sentence: Likewise, the bytes used to encode <period> and <slash> in the POSIX locale shall not occur as part of any other character in any locale. At line 1134 (XBD 3.2, Absolute Pathname), change: A pathname beginning with a single or more than two <slash> characters; to: A pathname beginning with a single or more than two slash bytes; At line 1647 (XBD 3.136, Dot), change: In the context of naming files, the filename consisting of a single dot character ('.'). to: In the context of naming files, the filename consisting of a single dot byte ('.'). At line 1650 (XBD 3.137, Dot-Dot), change: The filename consisting solely of two dot characters (".."). to: The filename consisting solely of two dot bytes (".."). At line 1782 (XBD 3.170, Filename), change: The characters composing the name may be selected from the set of all character values excluding the <slash> character and the null byte. to: The bytes composing the name shall not contain the null byte nor the slash byte. After line 1785 (XBD 3.170, Filename), add a new paragraph: A filename need not contain valid characters across all locales, unless it consists solely of bytes used to encode the set of portable filename characters. At line 2145 (XBD 3.266, Pathname), change: A character string that is used to identify a file. In the context of POSIX.1-2008, a pathname may be limited to {PATH_MAX} bytes, including the terminating null byte. It has an optional beginning <slash>, followed by zero or more filenames separated by <slash> characters. A pathname may optionally contain one or more trailing <slash> characters. Multiple successive <slash> characters are considered to be the same as one <slash>, except for the case of exactly two leading <slash> characters. to: A string that is used to identify a file. In the context of POSIX.1-2008, a pathname may be limited to {PATH_MAX} bytes, including the terminating null byte. It has an optional beginning slash byte ('/'), followed by zero or more filenames separated by slash bytes. A pathname may optionally contain one or more trailing slash bytes. Multiple successive slash bytes are considered to be the same as one slash byte, except for the case of exactly two leading slash bytes. At line 2155 (XBD 3.268, Path Prefix), change: The part of a pathname up to, but not including, the last component and any trailing <slash> characters, unless the pathname consists entirely of <slash> characters, in which case the path prefix is ’/’ for a pathname containing either a single <slash> or three or more <slash> characters, and ’//’ for the pathname //. The path prefix of a pathname containing no <slash> characters is empty, but is treated as referring to the current working directory. Note: The term is used both in the sense of identifying part of a pathname that forms the prefix and of joining a non-empty path prefix to a filename to form a pathname. In the latter case, the path prefix need not have a trailing <slash> (in which case the joining is done with a <slash> character). to: The part of a pathname up to, but not including, the last component and any trailing slash bytes, unless the pathname consists entirely of slash bytes, in which case the path prefix is ’/’ for a pathname containing either a single slash or three or more slash bytes, and ’//’ for the pathname //. The path prefix of a pathname containing no slash bytes is empty, but is treated as referring to the current working directory. Note: The term is used both in the sense of identifying part of a pathname that forms the prefix and of joining a non-empty path prefix to a filename to form a pathname. In the latter case, the path prefix need not have a trailing slash byte (in which case the joining is done with a slash byte). At line 2360 (XBD 3.318, Relative Pathname), change: A pathname not beginning with a <slash> character. to: A pathname not beginning with a slash byte. At line 2378 (XBD 3.324, Root Directory), change: pathnames that begin with a <slash> character. to: pathnames that begin with a slash byte. At line 2828 (XBD 3.439, Working Directory), change: pathnames that do not begin with a <slash> character. to: pathnames that do not begin with a slash byte. In lines 3001-3042 (XBD 4.12, Pathname Resolution), change all 13 instances of "<slash>" or "<slash> character" to "slash byte". In the following interfaces in XSH and XCU, change "<slash> character" to "slash byte": 19483 access 21089 bind 21720 catopen 22200 chmod 22368 chown 23412 connect 24591 dlopen 25721, 25913 exec 26554 fattach 27275 fdetach 29185 fopen 29568 fpathconf 30928 freopen 31710 fstatat 31897 fstatvfs 32107 ftok 32447 futimens 33433, 33545 getcwd 39848 lchown 40159 link 43632 mq_open 45330 open 46564 posix_spawn 48883 posix_typed_mem_open 55881 readlink 56109 realpath 56931, 57008 rename 58112 sem_open 59087 sendmsg 59212 sendto 60328 shm_open 67592 truncate 68051 unlink 68356 utime 78591, 78643, 78668 basename 80191, 80361 cd 81803 cp 84068, 84146 dirname 89045 find 92832 ln 97288 mv 99951 pax 101698 pwd At line 115603 (XRAT A.4.6, Filenames), change: The file system implementation historically deals only with bytes, not with characters, except for <slash> and the null byte. to: The file system implementation historically deals only with bytes, not with characters. Limitations on valid encodings ensure that the byte sequences for <slash> character, <period> character, and null character (as encoded in the POSIX locale) will not be confused with any other character in any other encoding. However, there exist common single-shift encodings where other single-byte characters from the portable filename set can also occur as a subset of a multi-byte character, making case-folding of portable filename bytes dependent on the context of whether a shift-state is active. At line 115615 (XRAT A.4.6 Filenames), change: Case folding is inconsistent with portable filename character set definition and filename definition (all characters except <slash> and null). No known implementations allowing all characters except <slash> and null also do case folding. to: Case folding is inconsistent with portable filename character set definition and filename definition (all bytes except <slash> and null). No known implementations allowing all bytes except <slash> and null also do case folding. At line 115734 (XRAT A.4.12, Pathname Resolution), change "<slash> character" to "slash byte" throughout the section. |
||||||
| Tags | tc1-2008 | ||||||
| Attached Files | |||||||
|
|
|||||||
|
Relationships |
|||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||
|
Notes |
|
|
(0000522) eblake (manager) 2010-08-12 15:09 edited on: 2010-08-12 16:29 |
Based on points raised during the 5 Aug 2010 meeting, the proposed action needs to be reworded. In particular, by carefully defining in which situations a filename represents a character string, and the fact that <period> and <slash> are uniquely identifiable across all supported locales, it is possible to have a well-defined meaning behind searching for a <slash> character within a (byte) string, even when the string does not consist solely of characters. Doing this reduces the overall amount of changes needed to the rest of the standard. In particular, no term "slash byte" is needed, and no changes to XSH are needed. After line 3589, (XBD 6.1, Portable Character Set), insert a new bullet: The encoded values associated with <slash> and <period> shall be invariant across all locales supported by the implementation. At line 3619 (XBD 6.2, Character Encoding), add a sentence: Likewise, the byte values used to encode <period> and <slash> shall not occur as part of any other character in any locale. At line 91229 (XCU iconv RATIONALE), add a new paragraph: The iconv utility may support the conversion between ASCII and EBCDIC based encodings, but is not required to do so. In an XSI-compliant implementation, the dd utility is the only method guaranteed to support conversion between these two charsets. At line 91233 (XCU iconv SEE ALSO), add a link to dd. At line 93178 (XCU locale RATIONALE), add a new paragraph: According to <xref to XBD 6.1>, the standard requires that all supported locales must have the same encoding for <period> and <slash>, because these two characters are used within the locale-independent pathname resolution sequence. Therefore, it would be an error if 'locale -a' listed both ASCII and EBCDIC based locales, since those two encodings do not share the same representation for either <period> or <slash>. Any system that supports both environments would be expected to provide two POSIX locales, one in either codeset, where only the locales appropriate to the current environment can be visible at a time. In an XSI-compliant implementation, the dd utility is the only portable means for performing conversions between the two charsets. At line 2145 (XBD 3.266, Pathname), change one paragraph: A character string that is used to identify a file. In the context of POSIX.1-2008, a pathname may be limited to {PATH_MAX} bytes, including the terminating null byte. It has an optional beginning <slash>, followed by zero or more filenames separated by <slash> characters. A pathname may optionally contain one or more trailing <slash> characters. Multiple successive <slash> characters are considered to be the same as one <slash>, except for the case of exactly two leading <slash> characters. into two paragraphs: A string that is used to identify a file. In the context of <current version>, a pathname may be limited to {PATH_MAX} bytes, including the terminating null byte. It has optional beginning <slash> characters, followed by zero or more filenames separated by <slash> characters. A pathname can optionally contain one or more trailing <slash> characters. Multiple successive <slash> characters are considered to be the same as one <slash>, except for the case of exactly two leading <slash> characters. Note: If a pathname consists of only bytes corresponding to characters from the portable filename character set (<xref to XBD 3.276>), <slash> characters, and a single terminating <NUL> character, the pathname will be usable as a character string in all supported locales; otherwise, the pathname might only be a string (rather than a character string). Additionally, since the single-byte encoding of the <slash> character is required to be the same across all locales and to not occur within a multi-byte character, references to a <slash> character within a pathname are well-defined even when the pathname is not a character string. However, this property does not necessarily hold for the remaining characters within the portable filename character set. At line 2199 (XBD 3.276, Portable Filename Character Set), add a sentence: See also <xref to XBD 3.266 Pathname>. At line 1647 (XBD 3.136, Dot), change: In the context of naming files, the filename consisting of a single dot character ('.'). to: In the context of naming files, the filename consisting of a single <period> character ('.'). At line 1650 (XBD 3.137, Dot-Dot), change: The filename consisting solely of two dot characters (".."). to: The filename consisting solely of two <period> characters (".."). At line 1782 (XBD 3.170, Filename), change: A name consisting of 1 to {NAME_MAX} bytes used to name a file. The characters composing the name may be selected from the set of all character values excluding the <slash> character and the null byte. The filenames dot and dot-dot have special meaning. A filename is sometimes referred to as a "pathname component". to: A sequence of bytes consisting of 1 to {NAME_MAX} bytes used to name a file. The bytes composing the name shall not contain the <NUL> or <slash> characters. In the context of a pathname, each filename shall be followed by a <slash> or a <NUL> character; elsewhere, a filename followed by a <NUL> character forms a string (but not necessarily a character string). The filenames dot and dot-dot have special meaning. A filename is sometimes referred to as a "pathname component". See also <xref to XBD 3.266 Pathname>. At line 107745 (XCU test RATIONALE), add a paragraph: It is noted that '[' is not part of the portable filename character set; however, since it is required to be encoded by a single byte, and is part of the portable character set, the name of this utility forms a character string across all supported locales. At line 115603 (XRAT A.4.6, Filenames), change: The file system implementation historically deals only with bytes, not with characters, except for <slash> and the null byte. to: The file system implementation historically deals only with bytes, not with characters. Limitations on valid encodings ensure that the byte sequences for the <slash> character, <period> character, and <NUL> character will not be confused with any other character in any locale. However, there exist common single-shift encodings where other single-byte characters from the portable filename character set can also occur as a subset of a multi-byte character, making case-folding of portable filename bytes dependent on the context of whether a shift-state is active. At line 115615 (XRAT A.4.6 Filenames), change: Case folding is inconsistent with portable filename character set definition and filename definition (all characters except <slash> and null). No known implementations allowing all characters except <slash> and null also do case folding. to: Case folding is inconsistent with the portable filename character set and filename definitions (all bytes except <slash> and null). No known implementations allowing all bytes except <slash> and null also do case folding. At line 114796 (XRAT A.3 definitions Filename), delete the two existing paragraphs about filename truncation, and replace it with: See <xref to XRAT A.3 pathname>. At line 115093 (XRAT A.3 definitions), add a new section: Pathname Pathnames historically allowed all bytes except for the <slash> and <NUL> characters. For compatibility with existing file systems, this usage is maintained throughout the standard by noting that a pathname need not be a valid character string in all locales. However, the properties of the portable filename character set are such that a pathname using only those characters and the <slash> is portable in all locales as a character string. At line 115933 (XRAT A.6.2 Character Encoding), add a new paragraph: The encoding for <slash> and <period> are required to be the same across all locales, in part because pathname resolution requires recognition of these bytes. It is a fortunate accident that all common shift-based encodings did not use either <slash> or <period> as a valid second byte in a multi-byte character. At line 115802 (XRAT A.4.12 Pathname Resolution), add a new paragraph: Earlier versions of this standard were unclear as to whether a pathname was required to be a character string or just a string. The <current version> is clear that filenames are just strings, and that pathname processing is locale-independent. |
|
(0000523) Don Cragun (manager) 2010-08-12 16:36 edited on: 2010-10-15 09:06 |
Interpretation response ------------------------ The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale: ------------- The description provided by the submitter and the notes to the editor below contain rationale for these changes. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- Make the changes suggested in Note: 0000522 and Note: 0000578 |
|
(0000578) geoffclare (manager) 2010-10-15 09:03 |
The following changes have been moved here from 0000293 so that they can be included in TC1. After lines 1786 and 2193 (XBD Definitions), add two new sections and renumber accordingly: 3.171 Filename String A string consisting of a filename followed by a <NUL> character. 3.275 Portable Filename A filename consisting only of characters from the portable filename character set. Note: applications should avoid using filenames that have the <hyphen> character as the first character since this may cause problems when filenames are passed as command line arguments. At line 2915 (XBD 4.7 Filename Portability), replace: Portable filenames shall not have the <hyphen> character as the first character since this may cause problems when filenames are passed as command line arguments. with: Note: applications should avoid using filenames that have the <hyphen> character as the first character since this may cause problems when filenames are passed as command line arguments. At line 7575 (XBD dirent.h DESCRIPTION), change: d_name[] Name of entry. to: d_name[] Filename string of entry. At line 7577 (XBD dirent.h DESCRIPTION), change: The character array d_name is of unspecified size, but the number of bytes preceding the terminating null byte shall not exceed {NAME_MAX}. to: The array d_name is of unspecified size, but shall contain a filename of at most {NAME_MAX} bytes followed by a terminating null byte. At line 7612 (XBD dirent.h RATIONALE), change: number of characters provided matches (or only slightly exceeds) the length of the filename. to: number of bytes provided matches (or only slightly exceeds) the length of the filename string. At line 730 (XBD 2.1.5.1), change "filename argument" to "pathname argument". At line 5566 (XBD 8.2 Internationalization Variables NLSPATH), change "filename" to "pathname". At lines 8933, 9060, and 9182 (XBD limits.h NAME_MAX, _POSIX_NAME_MAX, _XOPEN_NAME_MAX), change "bytes in a filename (not including the terminating null)" to "bytes in a filename (not including the terminating null of a filename string)". At line 9311 (XBD limits.h RATIONALE), change "filenames" to "pathnames". At line 11796 (XBD stdio.h FILENAME_MAX), change "filename string" to "pathname". At line 19512-19513 (XSH access EXAMPLES), change both instances of "filename" to "pathname". At line 20294 (XSH alphasort APPLICATION USAGE), change: If dir contains filenames that contain characters outside the domain of the collating sequence of the current locale, the alphasort() function need not provide a total ordering. to: If dir contains filenames that do not form character strings, or which contain characters outside the domain of the collating sequence of the current locale, the alphasort() function need not provide a total ordering. This condition is not possible if all filenames within the directory consist only of characters from the portable filename character set. At line 23739-23741 (XSH creat EXAMPLES), change both instances of "filename" to "pathname". At lines 25737 and 25741 (XSH exec DESCRIPTION), change both instances of "filename" to "filename string". At lines 26018 (XSH exec RATIONALE), change: The requirement on a Strictly Conforming POSIX Application also states that the value passed as the first argument be a filename associated with the process being started. Although some existing applications pass a pathname rather than a filename in some circumstances, a filename is more generally useful, since the common usage of argv[0] is in printing diagnostics. In some cases the filename passed is not the actual filename of the file; for example, many implementations of the login utility use a convention of prefixing a <hyphen> (’−’) to the actual filename, which indicates to the command interpreter being invoked that it is a "login shell". to: The requirement on a Strictly Conforming POSIX Application also states that the value passed as the first argument be a filename string associated with the process being started. Although some existing applications pass a pathname rather than a filename string in some circumstances, a filename string is more generally useful, since the common usage of argv[0] is in printing diagnostics. In some cases the filename passed is not the actual filename of the file; for example, many implementations of the login utility use a convention of prefixing a <hyphen> ('−') to the actual filename, which indicates to the command interpreter being invoked that it is a "login shell". At line 26577-26579 (XSH fattach EXAMPLES), change both instances of "filename" to "pathname". At line 27294-27296 (XSH fdetach EXAMPLES), change both instances of "filename" to "pathname". At line 29045 (XSH fnmatch NAME), change "filename" to "filename string". At line 29084 (XSH fnmatch APPLICATION USAGE), change "match filenames, rather than pathnames" to "match filename strings, rather than pathnames". At lines 29108, 29113, 29143, 29180, 29184 (XSH fopen), change all instances of "filename" to "pathname". At lines 30140-30150 (XSH fprintf EXAMPLES), change all instances of "filename" to "pathname". At lines 30870, 30877, 30881, 30885, 30893, 30914, 30923, 30927, 30939, 30964 (XSH freopen), change all instances of "filename" to "pathname". At line 31794 (XSH fstatat EXAMPLES), change "filename" to "pathname". At lines 34932-34949 (XSH getopt EXAMPLES), change all instances of "filename" to "pathname". At lines 40849-40860 (XSH localtime EXAMPLES), change all instances of "filename" to "pathname". At lines 49420, 42426, 42428, and 42430 (XSH mkdtemp DESCRIPTION), change "filename" to "pathname". At line 42465 (XSH mkdtemp EXAMPLES), change "Filename" to "Pathname". At lines 45377-45379 and 45409-45411 (XSH open EXAMPLES), change all instances of "filename" to "pathname". At line 46551 (XSH posix_spawn DESCRIPTION), change "filename" to "filename string". At line 46915 (XSH posix_spawn RATIONALE), change "filenames" to "pathnames". Delete lines 58669 and 58864 (XSH semget and semop EXAMPLES); "char filename[]" is unused in those examples. At line 66538-66539 (XSH tempnam EXAMPLES), change both instances of "filename" to "pathname". At line 67207 (XSH tmpnam DESCRIPTION), change "valid filename and that is not the same as the name of an existing file" to "valid pathname that does not name an existing file". At lines 67227-67235 (XSH tmpnam EXAMPLES), change all instances of "filename" to "pathname". At line 71031 (XSH wordexp APPLICATION USAGE), change "filename (or a list of filenames)" to "pathname (or a list of pathnames)". At line 98983 (XCU pathchk DESCRIPTION), change "Contains any character in any component that is not valid in its containing directory" to "Contains any byte sequence that is not valid in its containing directory". At line 114743 (XRAT A.3 Definitions Controlling Terminal), change "filename" to "pathname". At lines 115268, 115269, 115303, 115312 (XRAT A.3 Definitions Symbolic Link), change all instances of "filename" to "pathname". At line 115565 (XRAT A.4.6 Filenames), change "filenames" to "filenames and pathnames". At line 119442 (XRAT B.2.8.3 Memory Management), change "filenames" to "pathnames". At line 123577 (XRAT C.1.1 Change History), change "fixed path filenames" to "fixed pathnames". At line 125577 (XRAT D.2.2 Process Management), change "filename" to "pathname". |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2010-07-22 18:19 | eblake | New Issue | |
| 2010-07-22 18:19 | eblake | Status | New => Under Review |
| 2010-07-22 18:19 | eblake | Assigned To | => ajosey |
| 2010-07-22 18:19 | eblake | Name | => Eric Blake |
| 2010-07-22 18:19 | eblake | Organization | => Red Hat |
| 2010-07-22 18:19 | eblake | User Reference | => ebb.filename |
| 2010-07-22 18:19 | eblake | Section | => 3.170 |
| 2010-07-22 18:19 | eblake | Page Number | => 60 |
| 2010-07-22 18:19 | eblake | Line Number | => 1782 |
| 2010-08-12 15:09 | eblake | Note Added: 0000522 | |
| 2010-08-12 15:28 | eblake | Note Edited: 0000522 | |
| 2010-08-12 15:30 | eblake | Note Edited: 0000522 | |
| 2010-08-12 15:39 | eblake | Note Edited: 0000522 | |
| 2010-08-12 15:54 | eblake | Note Edited: 0000522 | |
| 2010-08-12 16:03 | eblake | Note Edited: 0000522 | |
| 2010-08-12 16:06 | eblake | Note Edited: 0000522 | |
| 2010-08-12 16:12 | eblake | Note Edited: 0000522 | |
| 2010-08-12 16:14 | eblake | Note Edited: 0000522 | |
| 2010-08-12 16:18 | eblake | Note Edited: 0000522 | |
| 2010-08-12 16:27 | eblake | Note Edited: 0000522 | |
| 2010-08-12 16:29 | eblake | Note Edited: 0000522 | |
| 2010-08-12 16:36 | Don Cragun | Interp Status | => --- |
| 2010-08-12 16:36 | Don Cragun | Note Added: 0000523 | |
| 2010-08-12 16:36 | Don Cragun | Resolution | Open => Accepted As Marked |
| 2010-08-12 16:38 | Don Cragun | Final Accepted Text | => See Note: 0000523 |
| 2010-08-12 16:38 | Don Cragun | Status | Under Review => Interpretation Required |
| 2010-08-13 08:18 | geoffclare | Interp Status | --- => Pending |
| 2010-09-13 05:48 | ajosey | Interp Status | Pending => Proposed |
| 2010-09-24 16:19 | geoffclare | Tag Attached: tc1-2008 | |
| 2010-10-15 09:03 | geoffclare | Note Added: 0000578 | |
| 2010-10-15 09:06 | geoffclare | Note Edited: 0000523 | |
| 2010-11-05 15:29 | ajosey | Interp Status | Proposed => Approved |
| 2011-04-11 21:58 | eblake | Relationship added | related to 0000293 |
| 2011-05-13 15:18 | eblake | Relationship added | related to 0000433 |
| 2011-05-13 15:34 | eblake | Relationship added | related to 0000439 |
| 2012-08-03 19:35 | eblake | Relationship added | related to 0000251 |
| 2013-04-16 13:06 | ajosey | Status | Interpretation Required => Closed |
| 2013-04-18 16:18 | eblake | Relationship added | related to 0000641 |
| Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |  |
