mcdonald

I created a CentOS (5.4) VM image, and hooked it into the remote build/test system. I'll review the results of the nightly builds/tests tomorrow morning.

I am looking into building a VM for CentOS 5.5; I expect that to be the hard part, since I think I can easily set up builds/tests using the remote build/test system once I create the image.

My intent in keeping up with upgrades is more to obtain fixes for security problems. Although, I'm not tracking specific open-source products to see if upgrades do in fact resolve security issues, and I don't expect to have time to do so. Sometimes upgrading is beneficial for obtaining bug fixes, especially for gcc. I'm OK with the "don't fix it if it isn't broken" way, but I also consider security vulnerabilities to be evidence of breakage and worth an upgrade.

Release archives are built and unit and system tests are run on Ubuntu 10.10 and Debian Lenny. The Debian Lenny VM I'm using to build has: # dpkg -l | grep "C Library" ii libc6 2.7-18lenny6 GNU C Library: Shared libraries ii libc6-dev 2.7-18lenny6 GNU C Library: Development Libraries and Hea ii libc6-xen 2.7-18lenny6 GNU C Library: Shared libraries [Xen version ii locales 2.7-18lenny6 GNU C Library: National Language (locale) da # Is 2.7 early enough? If it would be useful, I'll see about releasing the Debian Lenny builds as well as the Ubuntu builds for next release (although the Debian Lenny build won't be stress tested this time since I don't have a local machine running Lenny - it is the identical code and revision as is built on Ubuntu). Post if releasing this Debian build would help.

The fix was reviewed and committed yesterday, the nightly builds/tests succeeded/passed, I started a stress test just now. If everything goes well, next release should be Monday, March 14.

An engineer here found the cause of this problem, and fixed it. I was going to start testing today, but I'm still waiting for a code review on a fix for a race condition I discovered last Friday that causes a crash when adding torrents. Once the latter fix is reviewed and committed, and nightly builds/tests pass, I'll be starting a stress test on the next revision, which I would expect to be released next Monday, March 14.

The program should handle accepting a directory path whether or not it ends with a slash. However, since there is this work around, it is not as high a priority a bug.

Have you tried ensuring that all values you choose for dir_active/dir_completed and other path settings are terminated by a slash?

An engineer here committed changes to add a log entry whenever a torrent changes to an error state. That change won't be in the release I expect to have ready for today, but it will be in the next release.

utserver creates torrent data files (I think torrent files also) using the umask in effect when utserver is started. utserver creates files not intended to be exposed to non-administrative users (e.g., settings files) with access independent of the umask in effect when utserver is started. I made a note to add this to the documentation. All directories created by utserver are created with access 777 as you have noticed. If that's important to you, post one or more use cases for being able to vary access to directories created by utserver.

I've been running utserver on a Debian Lenny VM since yesterday and no crashes (no torrents either, but one user reported they saw a crash when no torrents were active). How about if everyone seeing this problem does the following: 1. set the logmask setting in the configuration files to 0xFFFFFFFF 2. set the -logfile option to generate a log file (specify a location large enough to handle a large log file) 3. run utserver (as daemon or not) 4. wait for a crash 5. look at (near the end of) the log file for anything interesting and post it if so Maybe we will see some common internal activities occurring immediately before the crash. I will work on a new release so that utserver incorporates any recent fixes in the main code line.

Currently there is one thread that performs all the just-completed torrent data file moves, according to the requests in its work queue. So, moves aren't interleaved; one move is performed and completed before the next move is started. No guarantee this implementation won't change, although I don't expect it to change. Of course, depending on what else you've got running on the computer, you can still have fragmentation. That's why I was mentioning preallocation. I used to do this on Windows' date=' as pre-allocation works fine there. It's been different using WINE on Linux, though, as it seems that either the pre-allocation routines are either not translated correctly to the OS layer by the WINE libs, or perhaps not all Linux FSes support pre-allocation?[/quote'] It's possible it may be a deficiency in uTorrent Server. I haven't tested pre-allocation. However, when I tried that option recently, I thought I saw the file size grow immediately rather than later. I need to look at the code and test this more carefully to confirm this. There isn't any work being done on preallocation on Linux. I can put it on my personal to-do list to at least see if it works or not, but I've got assigned tasks that have priority. I'll add a task to the issues list if I find it doesn't work.

A torrent data file move operation is requested for every just-completed torrent that needs it. The requests are queued for the thread that performs these operations. The operations will wait based upon the positions of the associated requests in the queue, but the requests are made immediately and rapidly; making the request won't block the requesting thread. Right now, a torrent data file move operation is done all at once and not interleaved with other operations. This non-interleaving behavior may change in the future so I would not recommend depending on it. I'd try preallocation of files as a strategy to avoid fragmentation, although preallocation won't help if you are moving files between file systems since the preallocation occurs on the files in the active directory, not the completed directory.

I think you will see better behavior because file moves are now done in a separate thread.

I don't think there's a target time to support that feature. I've added an item to the issue tracking system, so that people can discuss it at the next planning meeting.

It's OK with me, although mentioning in any web UI-related bug report that you are using a web UI different from what is distributed with the product would keep me from wasting time testing with the wrong web UI (better yet would be if possible to try with the included web UI before reporting). I won't necessarily test other web UIs, but if somehow a server bug is only reproduceable using another web UI, I'd try it. I think developers here are trying to keep the existing HTTP interface the same, adding new actions if new features are needed, although also changing/fixing behavior that we determine to be broken (e.g., the list-dirs action was broken until recently). I'd like to not prevent use of other web UIs. Eventually that action will probably be made to work on all releases, but that isn't the highest priority right now.

I'm trying to keep the branch from which uTorrent server closer to the leading edge of development efforts. As a result, the product will benefit from recent features and bug fixes, but some surprises may be introduced; I'd expect the surprises to be related to performance since the unit and system tests test behavior correctness not speed (although the tests will detect excessively long times to accomplish required tasks). I'll be rebranching soon, and that may pick up further work that reduces the sensitivity you are seeing, since I seem to recall some updates in uTP recently. If the next revision doesn't help, post and I'll add a report to our issue tracking system.

I hope that means it is working for everyone, especially those using Cyrillic character sets, for which the problem seemed most obvious. I don't have this problem.You may be have a problem with fonts! Previous revisions did have a problem with localization. I haven't heard any reports of localization problems with the latest release; no news can be good news. Sounds like you don't see that problem, which is a good sign.

The product will pick up the fix for labels when I rebranch the code line (probably this week). I haven't tried IE 9 beta. IE 8 will work on the next release after 23090 so maybe IE 9 will work too; I resolved a Javascript syntax problem that Firefox was OK with but IE would not accept.

Turns out that developer was working on the UDP proxy, which of course would not affect proxying of the web interface (TCP). I'll see if I can get some time to try to reproduce this.

Thanks for the report. I've asked a developer who recently worked on the Socks5 proxy to look at this.

I think I've discovered what caused that. The latest release actually works worse for those customers using cyrillic character sets, because the improvements in the code fixed one part of the issue but not another. I expect to have a release that resolves this early next week.

At the point the program completes downloading the torrent data files for the torrent. Whether the torrent is seeding or stopped after completion doesn't matter. If there is to be a move of the data files upon completion, the data files will be moved before the finish_cmd command is executed. If there is to be a move of the torrent file, the finish_cmd will be executed before the torrent file move if the torrent data files are not to be moved, and the finish_cmd will be executed in a separate thread (not necessarily after the torrent file is moved) if the torrent file is to be moved after completion.

Whoops - make that Monday.

This is a problem in multiple products. I based the most recent server release on a more recent branch, which has the advantage of picking up generic bug fixes and optimizations made since the previous branch (which was made about 8 months ago), but has the disadvantage of sharing with other products any not-yet-discovered bugs. I don't have a system test that tests label handling in the HTTP interface; I added that to my task list just now. The next release, which will go out Tuesday if all goes well, won't have a fix for this.