1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
|
$Id: Attributes,v 1.3 1999/02/01 01:56:25 jdp Exp $
Copyright 1999 John D. Polstra
CVSup File Attribute Encoding
Both in the protocol and in the "checkouts" files, various attributes
of files such as modification time, size, mode, and so forth have
to be represented. What we call "attributes" is an attempt to
encode this sort of information in an extensible way that can be
supported on a wide variety of platforms. To date, attributes have
been tested only on Unix systems. But there is reason to hope that
they will prove adequate for other platforms such as Windows NT too.
The attributes of a file are represented as a text string. The
string consists of a sequence of self-delimiting components, each
of the form:
count#value
where "count" is a decimal integer, and "value" is a string of
"count" characters. The "#" is included literally as shown. For
example, here are the attributes for one file:
3#1e71#19#8689852824#96753#jdp3#jdp3#6441#0
The individual components are:
3#1e7
1#1
9#868985282
4#9675
3#jdp
3#jdp
3#644
1#0
Although in this example the "count" is always one character, that
need not be the case.
The first component is always a hexadecimal mask indicating which
types of additional components are present in the rest of the
string. Here are the component types that are defined at present,
along with their masks:
FileType 0x00000001
ModTime 0x00000002
Size 0x00000004
LinkTarget 0x00000008
RDev 0x00000010
Owner 0x00000020
Group 0x00000040
Mode 0x00000080
Flags 0x00000100
In our example, the mask is 0x1e7, indicating that the FileType,
ModTime, Size, Owner, Group, Mode, and Flags are present.
The components present in the mask appear in order, from the least
significant "1" bit of the mask to the most significant "1" bit.
Components which are missing are either unknown or irrelevant.
Here is a description of each of the components.
FileType Decimal integer giving the type of the file:
Unknown 0
Regular file 1
Directory 2
Character device 3
Block device 4
Symbolic link 5
ModTime Decimal integer giving the modification time of the
file in standard Unix time format (seconds from the
epoch).
Size Decimal integer giving the size of the file in bytes.
LinkTarget Text string giving the target of a symbolic link.
RDev Hexadecimal integer giving the raw Unix device number.
Owner Text string giving the owner of the file.
Group Text string giving the group of the file.
Mode Octal integer giving the Unix file mode.
Flags Hexadecimal integer giving the FreeBSD file flags.
Depending on the context, certain components may be present for all
files, and certain components may be missing for all files, and
certain components may be present for some files but not for others.
Generally speaking, the FileType is always present, the ModTime and
Size are usually present, and the other attributes are present only
where they might prove useful.
At start-up time, the client and server negotiate a common set of
components that are supported by both sides. Any components not in
that common set are omitted. When two attributes are compared for
equality, only the components present in both attributes are
considered; the others are ignored.
The end.
|
