<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Hi Rafi,<br>
      <br>
      I have created a bug for this report which you will find at the
      following address:<br>
      <br>
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <a href="https://www.cendio.com/bugzilla/show_bug.cgi?id=4592">https://www.cendio.com/bugzilla/show_bug.cgi?id=4592</a><br>
      <br>
      <br>
      Regards,<br>
      <br>
      Henrik Andersson<br>
      <br>
      <br>
      On 04/04/2013 04:40 PM, Rafael Ostertag wrote:<br>
    </div>
    <blockquote cite="mid:515D90E8.4020500@math.uzh.ch" type="cite">Hi
      list
      <br>
      <br>
      We have a rather annoying issue here, involving the 64bit unfsd
      shipped with the ThinLinc client 4.0.0: when copying files to an
      exported volume on the client machine, we get 'Input/output
      error'. Sometimes it takes a while until copying files fails,
      other times it fails right away on the first file to copy.
      <br>
      <br>
      Tracing cp(1) using strace(1) revealed, that the open(2) syscall
      fails, when the O_EXCL flag is used in combination with O_CREAT,
      in order to create the destination file initially on the client
      machine, leaving an empty file behind. In case the destination
      already exists, cp(1) simply opens it using O_WRONLY|O_TRUNC which
      does not fail.
      <br>
      <br>
      So we basically end up with having to issue the copy command twice
      in order to copy a file to a volume: once in order to create the
      empty file and tricking the second attempt into passing
      O_WRONLY|O_TRUNC to open(2).
      <br>
      <br>
      This behavior is not limited to cp(1), Thunar (XFCE), Caja (MATE),
      and Nautilus also complain about Input/output error when files are
      initially created on the exported volume.
      <br>
      <br>
      We replaced the 64bit ThinLinc client by the 32bit version and the
      issue was gone. So, we strongly suspect the 64bit unfsd being the
      culprit.
      <br>
      <br>
      Does anybody else experience this behavior?
      <br>
      <br>
      Cheers
      <br>
      rafi
      <br>
      <br>
      P.S.: ThinLinc server is running Ubuntu 12.04 AMD64 and clients
      are running Ubuntu 12.04/12.10 AMD64. ThinLinc 4.0.0 on both ends.
      <br>
      <br>
      <br>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
---
Henrik Andersson
Cendio AB        <a class="moz-txt-link-freetext" href="http://cendio.com">http://cendio.com</a>
Teknikringen 8        <a class="moz-txt-link-freetext" href="http://twitter.com/ThinLinc">http://twitter.com/ThinLinc</a>
583 30 Linköping    <a class="moz-txt-link-freetext" href="http://facebook.com/ThinLinc">http://facebook.com/ThinLinc</a>
Phone: +46-13-214600    <a class="moz-txt-link-freetext" href="http://plus.google.com/112509906846170010689">http://plus.google.com/112509906846170010689</a></pre>
  </body>
</html>