similar to: FW: smbclient problems with very large files

Displaying 5 results from an estimated 5 matches similar to: "FW: smbclient problems with very large files"

2000 Apr 07
0
smbclient problems with very large files
> smbclient ls command doesn't like large files (eg >4.3Gb). The formatted > display goes wrong (as the number of bytes overflows the display), and > also the number of bytes displayed in the file is incorrect (I suspect it > is overflowing the maximum that it can hold). > > This has been a problem for a while - and is still a problem with samba > 2.0.7 pre3 > >
2006 Jun 27
0
Incremental Storage
Hello, I've been trying to figure out how to control the space required for backups using rsync, large files, and an incremental backup scheme. In particular, I've got two customers in which I'm creating Exchange backups using the built-in MS backup, then rsyncing an exchange.bks file nightly. One customer has a 4.3GB exchanges.bks file, and although rsync works wonderfully by only
2005 Aug 12
3
OT: Sendmail question
Hi, all I want voicemails to be delivered to recepients by e-mail. I have set up voicenail, and I can see asterisk is using sendmail to send messages out. Using Ethereal, I can see that messages are leaving my network, but receipeint mail server never replies back. As a result, mail delivery is timed out. I got a book on sendmail and it looks quite complex. It will take quite a bit of time
2008 Dec 04
5
Burning DVD with files>4GB from console
My backup script split filesystem dumps to files with size of 4,37 GB (4 588 544 kB). It's just an optimal size to fill out DVDs. At this moment I have to burn them from windows via smb-link becuase I didn't manage to do this task from FreeBSD console due to 2GB/4GB filesize restrictions (growisofs). I'm using freeware CDBurnerXP to burn my backups (ISO9660/UDF/Joliet), and they
2017 Jul 01
4
[RFC] Placing profile name data, and coverage data, outside of object files
On Fri, Jun 30, 2017 at 5:54 PM, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Problem > ------- > > Instrumentation for PGO and frontend-based coverage places a large amount > of > data in object files, even though the majority of this data is not needed > at > run-time. All the data is needlessly duplicated while generating archives, > and > again while