This the summary:
Most interresting is the gap between the beginning of the transaction and the actual
writing (writing begins at about 45sec)
Any traffic above this point is just minor. After the 45sec the real transfer begins.
As I found no way to search for checksum errors, I didn't found
These are the details from the packets from 16s to 57 s.
Frame 26 (54 on wire, 54 captured)
Arrival Time: Jun 23, 2002 13:34:17.620511000
Time delta from previous packet: 0.7 seconds
Time relative to first packet: 16.173765000 seconds
Frame Number: 26
Packet Length:
Hi Lars,
Just a guess, but what I see is a zero byte write request a offset
719970304; a zero byte write request to an offset beyond the eof is
typically used by ms applications to
'extend' a file, ie make sure physical space adequate for the entire
eventual operation is available before
I am seeing some inconsistencies on files that have very similar names.
Here is my share:
[ftp]
comment = FTP Directories
path = /home
browsable = yes
writeable = no
valid users = csr,system,technical,financial
write list = system
force
Hi all,
I'm still trying to debug an issue with smbsh on a Redhat 7.3
configuration, using Samba 2.2.5.
When `smbsh` is run on the system, we see output like this:
[root@ejecllab01 bin]# ./smbsh
[2002/06/24 15:08:49, 0] smbwrapper/shared.c:smbw_setup_shared(52)
Username: user
Password: pass
Sorry, forgot version.
2.2.4
Here is how it was configured:
configure \
--with-automount \
--with-smbmount \
--with-pam \
--with-mmap \
--with-quotas \
--without-smbwrapper \
--with-libsmbclient \
--with-utmp \
Y
ou're right, the machine is filling up a tempfile. During the pause between
write-request and writing my machine has heavy disk activity. When I copy a very
large file (large than this one) the win-client times out after 60 seconds and a file
containing zeros is stored where the copy should
