[Documentation] Added a document to track problems with file transfer protocol extens...

git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3401 3789f03b-4d11-0410-bbf8-ca57d06f2519

diff --git a/doc/ft-protocol-problems.txt b/doc/ft-protocol-problems.txt
new file mode 100644 (file)
index 0000000..b0198fb
--- /dev/null
+++ b/doc/ft-protocol-problems.txt
@@ -0,0 +1,35 @@
+From: Peter Rosin <peda@lysator.liu.se>\r
+To: vnc-tight-list@lists.sourceforge.net\r
+Date: Thu, 25 Sep 2008 10:21:07 +0200\r
+Message-ID: <48DB49F3.6030609@lysator.liu.se>\r
+Subject: Problems with timestamps in file transfers.\r
+\r
+Hi list!\r
+\r
+I'm writing some VNC client software that supports the the file\r
+transfer extensions described in the rfbtight.tex document in\r
+the svn repo. However, when I communicate with a TightVNC server\r
+version 1.3.9 (WinVNC.exe) I get strange data for the modification\r
+times of the files.\r
+\r
+Specifically, in the FileListData message, I have understood\r
+that directories are encoded as <size ~0, mod-time 0>. For\r
+regular files I get the expected size, but the mod-time is\r
+always 0xffffffe7 (-25) which seem totally bogus.\r
+\r
+The next problem is more disturbing since you will get interop\r
+problems if you fix it. In the last FileDownloadData message\r
+(the one with raw-length = compressed-length = 0), the mod-time\r
+is transmitted in little-endian byte order (at least my TightVNC\r
+server does so). Since it's more problems fixing this than\r
+documenting it, I think this endianness issue should be recorded\r
+in the rfbtight.tex file.\r
+\r
+(However, when you use FileUploadData you should transmit\r
+  the mod-time in the expected big-endian network byte order.)\r
+\r
+Cheers,\r
+Peter\r
+\r
+==================================================================\r
+\r