bogos

running the current build (24733), i have the following problem: whilst downloading torrents that contain only a single file works fine, adding torrents that contain folders shows the following behavior: the topmost directory of the torrent isn't created in my download destination directory, any second or third level directories however are. in terms of directory settings, my utserver.conf reads only this: dir_root: /media/dl/bt/ dir_active: /media/dl/bt/ no on-completion-moving or anything, files stay wherever they were created fs: /dev/sda6 on /media/dl type ext4 (rw,grpid,commit=0) rights: drwxrwxrwx 8 bogos plugdev 12K 2011-03-04 02:13 /media/dl/bt/ consider a torrent that would usually create folders/files: /media/dl/bt/torrentname/file1.txt /media/dl/bt/torrentname/folder1/file2.txt /media/dl/bt/torrentname/folder2/file3.txt utorrent server instead creates this following folder structure: /media/dl/bt/file1.txt /media/dl/bt/folder1/file2.txt /media/dl/bt/folder2/file3.txt plus an additional file /media/dl/bt/bt that has zero bytes rights of /media/dl have been set to 777 for test purposes, evidently utorrent server can write to it, it just doesn't properly create folders. have tried this using torrent file add as well as torrent url add using both the webui from the .tar.gz and the WIP one. verbose log files don't seem to have anything relevant in them. halp.

that is a restriction imposed by linux - in order to listen to ports lower than 1024, you need root privileges on linux systems.

hey there, thanks for taking an interest in this issue. i currently don't have any torrents added. utserver ran for around half an hour before it crashed and with the logmask and logfile parameter set, these are the last lines that i get: http://pastie.org/pastes/1432748/text?key=jerkvml9jrd3jamtdvneea the apparently cyclic status evaluaton goes on for most of the log only to be interrupted by the occasional disconnection from some peers because the torrent hash they're asking for is none i have added. utserver ran as -daemon there. i somehow doubt this helped. i can however note that reverting to the second latest version (23090) seems to fix the issue.

i have the same issue, just that the duration the server will run for varies greatly. one sample segfault is this (coming from an ubuntu 9.10 server): segfault at 630 ip b775a14c sp b65abf24 error 4 in libc-2.9.so[b76e1000+15c000] i haven't tried running it non-daemonized, will do that now to see if that stops it from bogging down.