Bandwidth not counted when downloading with filemanager

[113345]

Hi,

I found that the bandwidth is not counted when downloading with filemanager, however uploads are counted.
I downloaded a backup with filemanager, then did:
echo "action=tally&value=all" >> /usr/local/directadmin/data/task.queue
No change in bandwidth usage
I uploaded a backup with filemanager, then did:
echo "action=tally&value=all" >> /usr/local/directadmin/data/task.queue
Bandwidth usage changed.
I am using FreeBSD 4.9 and DA v1.22.2
Is this a bug?

[DirectAdmin Support]

Hello,

Thanks for the note. It actually is logged, but just happens to be jailed when the log is written to, so DA is trying to store the bandwidth file in /home/username/usr/local/directadmin/data/users/DAdminUsage.bytes

I'll have to log the bandwidth before the file is sent, however this assumes that the whole file is going to be sent. If they click a 10 meg file then cancel within 1 second, they'll still be hit with 10 meg of usage.

John

[113345]

It looks like the transfer is not logged:

www1# more DAdminUsage.bytes
8882
10376
www1# more DAdminUsage.bytes
8882
10376
www1# more DAdminUsage.bytes
8882
10376
(now I transfer a 8 MB file)
www1# more DAdminUsage.bytes
8882
10376
183
(now I run the "echo "action=tally&value=all" >> /usr/local/directadmin/data/task.queue")
www1# more DAdminUsage.bytes
DAdminUsage.bytes: No such file or directory
Total bandwith usage is very close to the bandwidth I started with (few kbytes more)

[DirectAdmin Support]

Correct. The fix will be available for the next release.

John

[113345]

Thanks :)

Most of my users download their backups using file manager.
It ads up.

[ClayRabbit]

Currently DAdminUsage.bytes counting is a nightmare!

Se what i found today:
User have backup-Nov-9-2004-1.tar.gz file, it's size 25 Mb.

Now, let's see what we have in /var/log/directadmin/2004-Nov-09.log

===
09/11/2004:22:23:09 217.107.253.137 GET /CMD_FILE_MANAGER/backups/backup-Nov-9-2004-1.tar.gz HTTP/1.1 henshin
09/11/2004:22:23:16 217.107.253.137 GET /CMD_FILE_MANAGER/backups/backup-Nov-9-2004-1.tar.gz HTTP/1.1 henshin
09/11/2004:22:23:16 217.107.253.137 GET /CMD_FILE_MANAGER/backups/backup-Nov-9-2004-1.tar.gz HTTP/1.1 henshin
09/11/2004:22:23:16 217.107.253.137 GET /CMD_FILE_MANAGER/backups/backup-Nov-9-2004-1.tar.gz HTTP/1.1 henshin
09/11/2004:22:23:16 217.107.253.137 GET /CMD_FILE_MANAGER/backups/backup-Nov-9-2004-1.tar.gz HTTP/1.1 henshin
09/11/2004:22:26:28 217.107.253.230 GET /CMD_FILE_MANAGER/backups/backup-Nov-9-2004-1.tar.gz HTTP/1.1 henshin
09/11/2004:22:26:28 217.107.253.230 GET /CMD_FILE_MANAGER/backups/backup-Nov-9-2004-1.tar.gz HTTP/1.1 henshin
09/11/2004:22:27:13 217.107.253.230 GET /CMD_FILE_MANAGER/backups/backup-Nov-9-2004-1.tar.gz HTTP/1.1 henshin
===
So, we see 8 hits.
And for every hit DA adds line with complete size of file (26171301) in DAdminUsage.bytes.
Ho many times this file was downloaded actually? Nobody knows, but I'm sure - it was downloaded completely only once. But DA will rise BW usage value by 25*8=200 (!) Meg.

Just made an experimet - started downloading that file and cancelled download after 50 Kb. And yes, 26171301 value is added to DAdminUsage.bytes. BUT ACTUALLY I'M NOT WASTED SUCH AMOUNT OF BW!!!
Now wonder if backup file size will be over 200 or even 500 Mb...

I'm not experienced in http-server development so I don't know how hard to made correct BW counting (like it's done in Apache, for example), but that issue must be corrected, or we need an option to disable BW counting inside DA at all.

I'd rather give a piece of bandwidth to my customers for free than receive their complains about disappeared bandwidth.

[ClayRabbit]

BTW: We need ability to determine the source of BW usage.
Currently DA not provides enough information for that.
We have only bandwidth=X in data/users/*/user.usage and
bandwidth=Y in data/users/*/domains/*/*.usage
What if X is more than Y ? We need to grep over ftp and directadmin logs to find what caused this. When (If) DA will count email BW also - we'll need to grep over smtp and pop3 logs also.
And if someone need to add BW counting from some custom service?

So I think that's a reason for another feature request - redesign BW counting scheme to make it more flexible and more visual.