diff options
| author | Constantin Kaplinsky <const@tightvnc.com> | 2008-12-17 06:38:54 +0000 |
|---|---|---|
| committer | Constantin Kaplinsky <const@tightvnc.com> | 2008-12-17 06:38:54 +0000 |
| commit | edf787ec777ca4c0e9a4f5730edd7ca7de3365f1 (patch) | |
| tree | a2b3dee1cfb9648891b0313667debf9384ca0132 | |
| parent | 173ac44e4d6330f89d2064bec61509db1cb33369 (diff) | |
| download | tigervnc-edf787ec777ca4c0e9a4f5730edd7ca7de3365f1.tar.gz tigervnc-edf787ec777ca4c0e9a4f5730edd7ca7de3365f1.zip | |
[Documentation] Added a document to track problems with file transfer protocol extensions, included an e-mail from Peter Rosin on this subject.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3401 3789f03b-4d11-0410-bbf8-ca57d06f2519
| -rw-r--r-- | doc/ft-protocol-problems.txt | 35 |
1 files changed, 35 insertions, 0 deletions
diff --git a/doc/ft-protocol-problems.txt b/doc/ft-protocol-problems.txt new file mode 100644 index 00000000..b0198fbc --- /dev/null +++ b/doc/ft-protocol-problems.txt @@ -0,0 +1,35 @@ +From: Peter Rosin <peda@lysator.liu.se>
+To: vnc-tight-list@lists.sourceforge.net
+Date: Thu, 25 Sep 2008 10:21:07 +0200
+Message-ID: <48DB49F3.6030609@lysator.liu.se>
+Subject: Problems with timestamps in file transfers.
+
+Hi list!
+
+I'm writing some VNC client software that supports the the file
+transfer extensions described in the rfbtight.tex document in
+the svn repo. However, when I communicate with a TightVNC server
+version 1.3.9 (WinVNC.exe) I get strange data for the modification
+times of the files.
+
+Specifically, in the FileListData message, I have understood
+that directories are encoded as <size ~0, mod-time 0>. For
+regular files I get the expected size, but the mod-time is
+always 0xffffffe7 (-25) which seem totally bogus.
+
+The next problem is more disturbing since you will get interop
+problems if you fix it. In the last FileDownloadData message
+(the one with raw-length = compressed-length = 0), the mod-time
+is transmitted in little-endian byte order (at least my TightVNC
+server does so). Since it's more problems fixing this than
+documenting it, I think this endianness issue should be recorded
+in the rfbtight.tex file.
+
+(However, when you use FileUploadData you should transmit
+ the mod-time in the expected big-endian network byte order.)
+
+Cheers,
+Peter
+
+==================================================================
+
|