| delorie.com/archives/browse.cgi | search |
| X-Recipient: | archive-cygwin AT delorie DOT com |
| DomainKey-Signature: | a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id |
| :list-unsubscribe:list-subscribe:list-archive:list-post | |
| :list-help:sender:subject:to:references:from:message-id:date | |
| :mime-version:in-reply-to:content-type; q=dns; s=default; b=yvwc | |
| KfO8ixXAGgxM50S90t+n4LUnbjKc+HOixu1A9ApVM1C0vx0iTnTLErVaWsBAn44B | |
| BM+0/TVh39taGJzkVn/cLlfW1gRphiK1eCGB+Ps8reQ8DJPY4On6xxDR6OuzN3DG | |
| tiqakLnTLyfD/QVDY0M4zE2vBW/wbFlP7r3iQZY= | |
| DKIM-Signature: | v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id |
| :list-unsubscribe:list-subscribe:list-archive:list-post | |
| :list-help:sender:subject:to:references:from:message-id:date | |
| :mime-version:in-reply-to:content-type; s=default; bh=3BPI5cBHfX | |
| 1a5x3ZqS8+LNrodBo=; b=e+GJ11fAUF6gHyHvepLQCZvzGpTF25rxMCqVSHXL8i | |
| mtzmquvBBOu41r3tl8v6XqXVIY9e6IgZv/F8oP7I1pzQhrGstEVf54mrfyp+Plk0 | |
| AlpWIk6oxcVlBCwXY0xhdOUrcsEYa2q8fFeavKSBT7gOlTK7Jy80cY0a7HOee9pk | |
| I= | |
| Mailing-List: | contact cygwin-help AT cygwin DOT com; run by ezmlm |
| List-Id: | <cygwin.cygwin.com> |
| List-Subscribe: | <mailto:cygwin-subscribe AT cygwin DOT com> |
| List-Archive: | <http://sourceware.org/ml/cygwin/> |
| List-Post: | <mailto:cygwin AT cygwin DOT com> |
| List-Help: | <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs> |
| Sender: | cygwin-owner AT cygwin DOT com |
| Mail-Followup-To: | cygwin AT cygwin DOT com |
| Delivered-To: | mailing list cygwin AT cygwin DOT com |
| Authentication-Results: | sourceware.org; auth=none |
| X-Virus-Found: | No |
| X-Spam-SWARE-Status: | No, score=0.0 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.3.2 |
| X-HELO: | sequoia-grove.secure-endpoints.com |
| X-MDAV-Result: | clean |
| X-MDAV-Processed: | sequoia-grove.secure-endpoints.com, Fri, 23 Oct 2015 10:30:51 -0400 |
| X-Spam-Processed: | sequoia-grove.secure-endpoints.com, Fri, 23 Oct 2015 10:30:50 -0400 |
| X-Spam-Report: | * -0.0 NO_RELAYS Informational: message was not relayed via SMTP |
| VBR-Info: | md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; |
| X-MDArrival-Date: | Fri, 23 Oct 2015 10:30:50 -0400 |
| X-Return-Path: | prvs=1738c1b933=jaltman AT secure-endpoints DOT com |
| X-Envelope-From: | jaltman AT secure-endpoints DOT com |
| X-MDaemon-Deliver-To: | cygwin AT cygwin DOT com |
| Subject: | Re: Error accessing mapped drive >2TB? |
| To: | cygwin AT cygwin DOT com |
| References: | <CA+2x6-L_pqdN6PHE0c15hcmrmB66Z75Hz95cH+dbcn4yXuVZNg AT mail DOT gmail DOT com> <712A87EA-64C7-4033-BE7F-39C8C8D527EB AT etr-usa DOT com> <20151021100328 DOT GL5319 AT calimero DOT vinschen DOT de> <CB8461F5-FB0E-44D8-81BB-B52DD02AD400 AT etr-usa DOT com> <20151021162254 DOT GC19868 AT calimero DOT vinschen DOT de> <169BF9F6-FF26-4073-9CC4-786882EFBAE9 AT etr-usa DOT com> <20151022083446 DOT GW5319 AT calimero DOT vinschen DOT de> <B8DBF0B5-51A9-4833-92D5-CA9E08B27DEC AT etr-usa DOT com> <20151023092007 DOT GF5319 AT calimero DOT vinschen DOT de> |
| From: | Jeffrey Altman <jaltman AT secure-endpoints DOT com> |
| Openpgp: | id=FA444AF197F449B24CF3E699F77A735592B69A04; url=http://pgp.mit.edu |
| X-Enigmail-Draft-Status: | N1110 |
| Message-ID: | <562A4495.5010705@secure-endpoints.com> |
| Date: | Fri, 23 Oct 2015 10:30:45 -0400 |
| User-Agent: | Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 |
| MIME-Version: | 1.0 |
| In-Reply-To: | <20151023092007.GF5319@calimero.vinschen.de> |
--------------ms050207010103030304000704
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
In this thread there appears to be a small amount of misunderstanding of
what a reparse point is and how it should be used.
A reparse point can be thought of as a special form of extended
attribute on a file system object (directory or file) that can stored a
single {tag-value, opaque-data} pair. In general, applications are not
expected to understand the meaning of the opaque-data nor should they
need to know what all of the registered tag-values are.
The reparse data is meant for the file system to interpret. Some of the
opaque data structures necessary to interpret tag-values registered for
NTFS are included in the Windows DDK ntifs.h header. For example, the
structures for the IO_REPARSE_TAG_SYMLINK (0xA000000CL) tag and
IO_REPARSE_TAG_MOUNT_POINT (0xA0000003L) tag are included in the struct
_REPARSE_DATA_BUFFER. But there are nearly a dozen other Microsoft
registered tag values and dozens on non-Microsoft registered tag values
for which the data structures are not published.
The high bits of the tag-value convey information. There is a Microsoft
bit (0x80000000L) and a Surrogate bit (0x20000000). If the Surrogate
bit is set in the tag value then the directory entry is a placeholder
for another object. Examples, a junction has the surrogate bit set to
indicate that the target of the junction is the root directory of
another file system. A symlink has the surrogate bit set to indicate
that the target is a different file or directory that might or might not
be in a different file system.
In this thread a statement was made that the Explorer Shell does not pay
attention to reparse points. Actually, the Explorer Shell maintains a
cache of all objects and in particular where there reparse points are.
Each surrogate reparse point is a potential bridge to a new file system.
That means that volume information queries must be evaluated on the
target side of the reparse point. There was a long standing bug in
this caching that has only been fixed in Windows 10.
The CreateFile() API when applied to a reparse point will by default
allocate a handle to the reparse point target. In order to obtain a
handle to the object on which the reparse point attribute is set the
FILE_FLAG_OPEN_REPARSE_POINT flag must be set.
The GetFileAttributes() and GetFileAttributesEx() API calls set the
FILE_FLAG_OPEN_REPARSE_POINT flag which is why GetFileAttributesEx()
returns the size of the reparse point data and not the size of the
target object. This is a point of confusion especially when working
with NTFS Symlinks because .NET and Java are unaware of Symlinks and use
the wrong size when parse the target data stream.
Lets discuss what is going on in this particular case. Apple
constructs their file namespace as the machine name representing a
virtual directory containing mount points to partitions and end user
folders.
Apple's SMB security requires that an authenticated connection be
established before viewing the available shares. I have created a
drive letter mapping of R: to one of the partitions.
For example:
]net view \\172.16.16.xx
Shared resources at \\172.16.16.xx
Share name Type Used as Comment
---------------------------------------------------------------------------=
----
BOOTCAMP Disk
jaltman Disk
Jeffrey Altman's Public Folder Disk
Macintosh HD Disk R:
The command completed successfully.
Apple's SMB file namespace (as is also true for the /afs file namespace)
permits the crossing of mount points without the use of a DFS referral
to a share representing the root directory of the target. As a result
the Apple SMB server does expose the existence of the mount point via
the use of the RP file attribute.
]getfileattrs.exe r:\
Attribute: 0x410
Directory
Reparse Point
]getfileattrsex.exe r:\
Attribute: 0x410
Directory
Reparse Point
Size: 0x0:0
Note that the size of the reparse data is zero. There is no reparse
data to read. This is a UNIX mount point not an NTFS junction.
]getfileinfobyhandle.exe r:\
Attribute: 0x410
Directory
Reparse Point
ReparseTag: 0xa0000003 Microsoft Surrogate
Size: 0x0:0
EOF: 0x0:0
Links: 1
Delete? no
Directory? yes
Apple should have registered with Microsoft their own reparse point tag.
Instead they broke the rules and used Microsoft's
IO_REPARSE_TAG_MOUNT_POINT which can lead to confusion except for the
fact that the SMB server is clearly indicating that there is no reparse
data to read by setting the size to 0. The error status
STATUS_NOT_A_REPARSE_POINT (0xC0000275L) is what is generated when there
is no reparse data to read.
]getvolumeinfobyhandle.exe r:\
File System: NTFS
Volume Name: Macintosh HD
Serial: 0
Max Component Length: 255
System Flags: 0x40086
Case Preservation
Named Streams
Supports Reparse Points
Unicode on Disk
Apple also broke the rules by reusing the IO_REPARSE_TAG_SYMLINK tag
since they do not expose the reparse data for symlinks.
]dir r:\
Directory of R:\*
10/23/2015 9:21 <JUNCTION> . [R:\.]
10/23/2015 9:21 <JUNCTION> .. [R:\..]
10/01/2015 18:56 <JUNCTION> afs [R:\afs]
10/22/2015 18:53 <DIR> Applications
7/21/2011 22:15 <DIR> Incompatible Software
10/22/2015 14:04 <DIR> Library
10/22/2015 14:06 <DIR> System
9/30/2015 8:33 <DIR> Users
1/24/2011 23:27 <SYMLINK> User Guides And Information
[\Library\Documentation\User Guides and Information.localized]
0 bytes in 1 file and 8 dirs
60,172,144,640 bytes free
]getfileinfobyhandle.exe "r:\User Guides And Information"
Attribute: 0x420
Archive
Reparse Point
ReparseTag: 0xa000000c Microsoft Surrogate
Size: 0x0:0
EOF: 0x0:0
Links: 1
Delete? no
Directory? no
You might also not that Apple does not expose volume serial numbers. So
the serial number on either side of a mount point will always be zero.
]getvolumeinfobyhandle.exe r:\afs\
File System: NTFS
Volume Name: Macintosh HD
Serial: 0
Max Component Length: 255
System Flags: 0x40086
Case Preservation
Named Streams
Supports Reparse Points
Unicode on Disk
Therefore, applications cannot rely on the serial numbers to distinguish
between devices. Instead, the applications must do as the Explorer
Shell does and track the locations of the RP attributes in paths as they
are encountered.
Remember that there is no requirement that SMB servers expose reparse
points at all nor is there any requirement that they expose volume
information.
While Apple's design choices do not fit with the expectations of Cygwin
they are not necessarily wrong.
I hope this e-mail is helpful.
Jeffrey Altman
--------------ms050207010103030304000704
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG
9w0BBwEAAKCCDV0wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G
CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNp
Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4
BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6
ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGlj
IFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5
MDEwMDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsG
A1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVj
IFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl
ZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNj
cmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMbsJ/0dY/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrG
iBeGYXITdi7sA8snm48ggDfg5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3
ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icvYN+W8hoqjDyPAMxPy/og
jrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1Hiot
3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m
4uW5yuDzhXc1mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJA
MDgGCCsGAQUFBwEBBCwwKjAoBggrBgEFBQcwAYYcaHR0cDovL3BraS1vY3Nw
LnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEAMGwGA1UdIARlMGMw
YQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h
dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRo
LmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2ln
bi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMCkGA1UdEQQiMCCk
HjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNVHQ4EFgQUrfnD
k3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkG
A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW
ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJp
U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQD
EzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRp
b24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3
DQEBBQUAA4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolr
wA40Q5+kmeak8F1IM2KFhWH+I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT
6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRwYk3v0RC+nUgsXuyGaweC
8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXBAD9G
J4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt
1iqoyd7ZAAJP4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIH
EzCCBfugAwIBAgIQQA2IH1dlro2ulxZcz+4MMjANBgkqhkiG9w0BAQUFADCB
pjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9u
MR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ
ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz
IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTQxMjE4MDAw
MDAwWhcNMTUxMjE5MjM1OTU5WjCBzjEuMCwGA1UEAwwlUGVyc29uYSBOb3Qg
VmFsaWRhdGVkIC0gMTQxODg4MjEwMTAyMDErMCkGCSqGSIb3DQEJARYcamFs
dG1hbkBzZWN1cmUtZW5kcG9pbnRzLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4w
HAYDVQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFu
dGVjIFRydXN0IE5ldHdvcmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0
aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxnG6iSpLXZAJ
fuf957V+eQY5l/8a4s+wvFslpyNyHmih3Y+GGv1YUhn8QYufFKOFe8FflVwD
myvhJC4Dv7djnbVDsM9OEl/GUacmcb8OWJS+dInkUbZO0isRny1W8SVdaXxp
0QemjNczsbhE73bImHJU3KESVyqDB5VJqwvn+Ixdm8bug0D1aHeR6NpCXOVY
jtZm508+y9n7kVph/Wn0K2vEOlGiVpyR69WUqpFqY2tGthseOwvOQmH3wKE1
9fro7mMINCwPAt0S9BZxr2pR+HWpbH04KbJIRBlykaTDAJYvDqu2zjm9aMc4
jPfskefr99L2d+2nQtr8fC9ZuBe1lwIDAQABo4IDETCCAw0wDAYDVR0TAQH/
BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQG
CCsGAQUFBwMCMB0GA1UdDgQWBBTNie4wJCrT/MLp/t7Oa7+9uxA5HjAnBgNV
HREEIDAegRxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMB8GA1UdIwQY
MBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYBBQUHAQEEggEdMIIB
GTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u
Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlk
dWFsJTIwU3Vic2NyaWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0Ql
MjBQZXJzb25hJTIwTm90JTIwVmFsaWRhdGVkJTJDJTIwT1UlMjAlM0QlMjBT
eW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAlM0QlMjBTeW1h
bnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlm
aWNhdGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3Js
LnN5bWF1dGguY29tL2NhXzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4
MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBS
MCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggr
BgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTArBgpghkgB
hvhFARADBB0wGwYSYIZIAYb4RQEQAQICBAGGx85vFgUxMDkyMjA5BgpghkgB
hvhFARAFBCswKQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFD
NWpiMjA9MA0GCSqGSIb3DQEBBQUAA4IBAQC2axIcwU2XW8yc5xHsZFr2JiLt
QNrPAfeajH5NPGk74Ptw+hesFBnmVSf+8fL608SEPb72L3214wwXaVi51aFG
nhDNov/9esdtTR6nwBcOarUscuGEAE7kCKnr5PeitryCI4y/76yMGXr8DwT6
ZP14QCODH7s6PPW7k/qSQfaRFRPCAjVD1XbsnXGQCdEdJvKkFSLChGKgJFCw
9VOj/DipfGpW5RhZBbqlyEj23jJYODgPDOQVeSMRyBn1J14Thx/wC9cRPRlb
eA5hnfMvesvpYyR1f5g/dzbyWh9OFuqLpw2/EQVbfA0b6tDCx7VmqVB5Rt8x
/IvyCfKfY0OV3ckRMYIEYjCCBF4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0w
GwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50
ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRh
dGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi
c2NyaWJlciBDQSAtIEc0AhBADYgfV2Wuja6XFlzP7gwyMA0GCWCGSAFlAwQC
AQUAoIICdzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0xNTEwMjMxNDMwNDVaMC8GCSqGSIb3DQEJBDEiBCD4ALO9DH4wdKs/
dJCrrDStcLwXHE+Gefm5l+2JjxdzhjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCG
SAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC
AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHM
BgkrBgEEAYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRT
eW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3Qg
TmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYD
VQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD
QSAtIEc0AhBADYgfV2Wuja6XFlzP7gwyMIHOBgsqhkiG9w0BCRACCzGBvqCB
uzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0
aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENs
YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEEANiB9XZa6N
rpcWXM/uDDIwDQYJKoZIhvcNAQEBBQAEggEAaBgqvxu4NEonCZm+WTQ+GXEX
RAigZ0nPhEAU2XIKC2xBkvMzdeviZKPNMGOImddIaCygnd/Wnv3BmqMwEFmK
wO+I6/bee8eMFnQGcaXWYDQcOsjpbz1a40Gj8gIpVdKpM1wDDjNCdxj4lH+O
c0FCC4JKRJha3W0s2PjcvzEpbB1LodduNZZdfv9iboFZ5ks2A86bKuwBbcAW
904pvkCxQMsqINBLfZ9VIICqRsVXf5bIn8Cv5T0RWGViNQtbDGxOwyDCYx2P
/uaNghWVrQMvqXSGHOFBfTXEbDFuClWQYrOgQz7St9tcTM/RpUzt8DSSVNdj
ExTL2/xsZQpAZ10XLAAAAAAAAA==
--------------ms050207010103030304000704--
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |