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
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
related to 0000293Appliedajosey 1003.1(2008)/Issue 7 restricting readdir normalization of filenames 
related to 0000251Appliedajosey 1003.1(2008)/Issue 7 Forbid newline, or even bytes 1 through 31 (inclusive), in filenames 
related to 0000433Closedajosey 2008-TC1 Interactions between XSH/TC1/D1/0093 and 0092, 0101 
related to 0000439Closedajosey 2008-TC1 XSH/TC1/D1/0262 redundant 
related to 0000641Closedajosey 1003.1(2008)/Issue 7 symlink() path1 does not need to contain characters 

-  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
Powered by Mantis Bugtracker