• Content Count

  • Joined

  • Last visited

  • Days Won


About rdebath

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling
  1. , The problem to be solved in that thread was with UNC paths on windows. The problem in this thread is for ALL platforms and is a simple result of making the temp files 6 characters longer than the existing file they refer to. When the existing file name is the maximum length it can be (or nearly so) the file cannot be transferred because the temp file name will be too long for the filesystem. I propose the temp file name is in the (per share) .Sync directory with a name based on the info hash.
  2. ifoo, sorry I skipped a couple of steps. Strictly speaking your issue isn't a BTSync one the problem is that a filename on ext3/4 can only be upto 255 bytes long; your filename is long enough that the extra extension the BTSync adds takes it to 258 characters. combine that with UTF-8 and the base64 encoding that encfs uses and you have very short filenames ... this is too long "ヲァィゥェォャュョッアイウエオカキクケコサシスセソタチツテトナニヌネノハヒフヘホマミムメモヤユヨラリルレロワン" Add to that the fact that I really don't like the clutter that BTSync scatters around (eg the .!sync files) the obvious solution would be for BTSync to stop clutt
  3. Okay kos13, that's it. I want to be able to store the partial files in the .Sync directory (eg: .Sync/partial/7a/b8dc8456c25f132551f157c77a1888ef918fac.part ) NB: While they're at it clean up the clutter; move everything into the .Sync directory ... .Sync/Ignore, .Sync/Trash .Sync/ID .Sync/settings.dat .Sync/config.dat .Sync/metacache.db etc etc.
  4. You're right, It's each component of the path and it depends on the filesystem, 255 for ext3/4, around 140 for encfs on ext3 etc. Hmm, most of the time I've only got one Windows machine and the rest are Linux ... Though I haven't tried a UNC path to the share ∴ your to raise.
  5. The windows API is limited to 255 UCS2 characters, or with Windows 7 it's limited to 255 (two byte) words encoded using UTF16. Many Linux filesystems are limited to 255 Bytes normally encoded with UTF8 (BTSync seems to assume UTF8). I haven't seen BTSync taking any notice of the "short" filenames in Windows; I suspect it's a bug if it does. On windows relative paths only work in relation to the current directory; the current directory must begin with a mapped drive letter. BTW: UNC means Universal/Uniform Naming Convention, not anything to do with unicode. But in answer to your primary questio
  6. Something to add to my list. A callout (trigger) that fires before a file is modified (created or deleted). This could be used to implement a shared permission scheme with digital signatures (or just bloodymindedness) If this node doesn't like the change (eg the new file has the wrong digital signature) it can abort it in some way eg: Send a delete to the network. (perhaps by doing a rename of the old file out of the way, accept the change then rename the old one back) Send a rename of either the before or the after file so they don't collide. Sign the file and move it from the upload director
  7. Okay list of things to do to the server ... Create a new secret share (perhaps with a new empty directory) Edit any configuration on a share. Delete a share Pause a share; disconnect from clients pretend it's deleted but keep it so it can be resumed instantly. Delete the files and directories that are in or were in a share Fetch individual files from the server or upload them for sharing. Turn the debugging on/off and view/download the debug log. Local or remote call backs (run programs) from the server whenever files are created, removed or modified. Eg: anti virus; it'll need the ability to