Bug when using Append .!ut to incomplete files and Move completed down

[mamruoc]

When the download is a directory containing files, all files get the correct append (.!ut) when downloading.

Upon successfully download, the directory do get moved, but the files within the directory do not get the appended .!ut removed

Mam

[mcdonald]

When the download is a directory containing files, all files get the correct append (.!ut) when downloading.

Upon successfully download, the directory do get moved, but the files within the directory do not get the appended .!ut removed

Mam

I'm not able to reproduce this. I'm using the latest source code for the branch from which uTorrent server gets built. I don't think there's been code changes in that branch that would change this behavior since the last release. I'd be curious to see a more detailed description of your running conditions.

[mamruoc]

I'm not able to reproduce this. I'm using the latest source code for the branch from which uTorrent server gets built. I don't think there's been code changes in that branch that would change this behavior since the last release. I'd be curious to see a more detailed description of your running conditions.

Ok, my setup is like this:

I have a 32 bit KVM guest (Ubuntu 10.04.1 LTS) inside a KVM server (Also Ubuntu 10.04.1 LTS).

On server, I use ZFS-fuse as filesystem for storage:

dpkg -l | grep zfs

ii zfs-fuse 0.6.9-7 ZFS on FUSE

I use Samba to share the filesystem:

dpkg -l | grep samba

ii samba 2:3.4.7~dfsg-1ubuntu3.2 SMB/CIFS file, print, and login server for Unix

On the client, the filesystem is mounted using CIFS:

//server/downloads on /mnt/downloads type cifs (rw,mand,noexec)

So, my configuration of uTorrent server is:

In Preferences => General, I have as follow:

Append .!ut to incomplete files

and

Pre-allocate all files

are both selected and in the Preferences => Directories I have as follow:

Put new downloads in:

/mnt/downloads/downloading

Move completed downloads to:

/mnt/downloads/finished

Append the torrent's label is selected.

The result I base my problem upon is:

ls -l XXXX/*

-rwxr----- 1 t t 731334656 2010-10-05 16:48 XXXX/xxx.!ut

-rwxr----- 1 t t 4440 2010-05-28 11:48 XXXXX/xxx.!ut

XXXXX/XX:

total 3587

-rwxr----- 1 t t 3558529 2010-05-28 11:51 xxx.!ut

-rwxr----- 1 t t 27 2010-05-28 11:48 xxx.!ut

t@torrent:/mnt/downloads/finished/movies$ pwd

/mnt/downloads/finished/movies

This problem is found in ALL of my files downladed using the uTorrent server for Linux.

[mamruoc]

Following up on my own post, I think I may have found the problem:

Whenever the uTorrent server crashes and needs to re-hash, the error seems to occur.

Mam

[mcdonald]

Whenever the uTorrent server crashes and needs to re-hash, the error seems to occur.

Interesting. I did try again (I didn't try separate active and completed directories before) and I could not reproduce it.

If you could post a backtrace of the uTorrent server when it crashes in the debugger (or if there is an assertion failure report), that would be helpful.

I'll record the issue that the server doesn't record the state of the file naming so that when it restarts the !ut extension is removed from those files. Although, this may continue to occur if the crash happens before the settings file can be updated.

[mcdonald]

Whenever the uTorrent server crashes and needs to re-hash' date=' the error seems to occur.[/quote']

Interesting. I did try again (I didn't try separate active and completed directories before) and I could not reproduce it.

I'll record the issue that the server doesn't record the state of the file naming so that when it restarts the !ut extension is removed from those files.

Another engineer here tried to reproduce this but could not. This may be related to using KVM since neither he nor I used KVM in our attempts to reproduce your report.

[mamruoc]

Another engineer here tried to reproduce this but could not. This may be related to using KVM since neither he nor I used KVM in our attempts to reproduce your report.

That might be the case. Anyway, as the Linux version has been far more stable for me, this has not been an issue anymore, so this "ticket" may be closed. I'll reopen if I encounter the problem again.

Thanks