similar to: [PATCH] warning: comparison between signed and unsigned in function source@scp.c

Hi, I have made a patch which improves scp utility. It adds two new features: rate limit and resume support. With rate limit it's possible to limit transfer speed. Resume allows to continue file transfer where it was last interrupted. Also the progress meter was improved. Here is my patch, please send comments about it and what I can do better if there is something to fix. ---

I'm fond of the "-a" (archive) option of cp, and I'm a heavy user of scp, so I guess it's inevitable that I would eventually add support for "-a" to scp. :-) Actually, it's a "-L" flag for preserving symlinks, and a "-a" flag that is shorthand for "-Lpr". Please let me know if I'm not doing this right.... I made a great

< This patch is against openssh-2.5.2p2 > Here's a few lines we changed a while back in "scp.c" to get it to transfer large (>2GB) file on a 32-bit system using LFS. Obviously, you don't want the line hard-coded in that sets _FILE_OFFSET_BIT=64, but perhaps you could make it a configure option. (Is it already perhaps?) Do you agree that these lines are neccessary

I think my first send was eaten by elm.. Yuck I hate this programm.. Anyawys, first the disclaimer: This is barely tests, I submit this to the general population, but I will not submit this for review of rest of the OpenSSH team. Mainly because it is horrible at best. dealing with alarm() in a sane way is not fun. It does not compile clean, but works. IF anyone cares to clean it up..

Again, this has been lightly tested. I think there still are a few glitchs. 1. stole progressmeter() from scp.c - clean up and simplified a little to remove the 'flag' status. It now understands how to initialize itself and how to terminate itself. Along with a malloced status bar instead of the original fix width bar. 2. removed all initialization code from scp.c for progressmeter()

This is the LAST version I plan on doing.. If I hear no feed back good or bad. Then I'll assume I've wasted my time on a feature that people whine about but don't care to try. This is against 3.0.2pX so it should be VERY easy for anyone to test. - Ben diff -ur openssh-3.0.2p1/misc.c openssh/misc.c --- openssh-3.0.2p1/misc.c Tue Jul 3 23:46:58 2001 +++ openssh/misc.c Wed Feb 6

http://bugzilla.mindrot.org/show_bug.cgi?id=1192 Summary: warning: comparison between signed and unsigned Product: Portable OpenSSH Version: 4.3p2 Platform: amd64 URL: http://www.openbsd.org/cgi- bin/cvsweb/src/usr.bin/ssh/scp.c.diff?r1=1.121&r2=1.122& f=h OS/Version: All

A while back someone posted a patch for scp that updates it to deal with files > 2gb by using 64 bit offsets as defined by LFS (Large File Sumit). I belive the patch was tested on Linux but maybe not on other systems that support largefiles. I've tried this under Solaris and scp fails with a broken pipe on only the second write to the pipe between scp and ssh if the file is over 2gb. If

When copying from a remote host to a local filesystem with a strange block size, allocbuf() in scp.c seems to calculate an incorrect buffer size, causing the copy loop in sink() to write past the end of the buffer. For example, with smbfs, the optimal block size is negotiated when the client connects to the server, and is rarely a power of two. In my case it is 64560. This loop in sink() keeps

Hi, I've sent that patch once already but it seems more or less forgotten in the tumultuous days of the latest vulnerability. It adds a new define NO_IPPORT_RESERVED_CONCEPT which can be defined on platforms not supporting the concept of "privileged" ports only accessible by privileged users but which allow everyone to use these ports. This patch removes some Cygwin dependencies

Hi all, The code currently in CVS gives a compile warning: memory.c: In function 'FLAC__memory_alloc_aligned': memory.c:52: warning: cast from pointer to integer of different size memory.c:52: warning: cast to pointer from integer of different size The patch below fixes this warning by detecting the sizeof (void*) at configure time and then using that for a little pointer

I'm curious how to go about submitting a suggestion that affects both the original BSD version and the portable release. A few days ago I sent off a BSD-relative patch to openssh at openssh.com. Is this the right thing to do? I didn't hear anything back, but it's only been 3 days, so I'm probably just being too antsy. In the meantime, maybe someone else out there would like to

At work we have a large collection of scripts to move log and config files around. These depend on commercial (F-Secure) ssh/scp, as it supports the -u option to delete the source file after (successful) copying. That is the sole reason we can't run openssh on our 150+ unix boxes. I have attached a patch below, which adds the -u option to delete the source file after copying, provided there

https://bugzilla.mindrot.org/show_bug.cgi?id=1192 Darren Tucker <dtucker at zip.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #1142|0 |1 is obsolete| | --- Comment #5 from Darren Tucker <dtucker at

Under OpenSSH 1.2pre17 I can duplicate and Input/Output error for scp: Conditions: pc36 is a RH6.0/i386 box. abc.co.za is a RH5.2/i386 box. (private network) openssh 1.2 pre 17 on both boxes. Line between them is a 128k leased line. It works between two 10baseT machines. If the scrollbar is active, the scp fails, if it isn't active, scp works. Note that without the scrollbar, the file gets

To detect that a sequence number is done, we are doing math on unsigned integers so the result is unsigned too. Not what was intended for the <= comparison. The result is user stuck forever in flush call. Convert to int to fix this. Further, get rid of ({}) to make code clearer. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- I've put this on my vhost.git tree.

To detect that a sequence number is done, we are doing math on unsigned integers so the result is unsigned too. Not what was intended for the <= comparison. The result is user stuck forever in flush call. Convert to int to fix this. Further, get rid of ({}) to make code clearer. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- I've put this on my vhost.git tree.

Hi, I'm trying to know if an llvm::Value Object is signed or unsigned (when its Type is integer). I don't find where this information is located. Do you have an idea ? Julien Henry

Hello > I'm trying to know if an llvm::Value Object is signed or unsigned (when > its Type is integer). > I don't find where this information is located. > Do you have an idea ? Values cannot be signed or unsigned since they represent some object in memory / register. It's the operation which says whether the value should be treated as signed or not. -- With best

> Values cannot be signed or unsigned since they represent some object > in memory / register. It's the operation which says whether the value > should be treated as signed or not. Ok. But typically if I compile a program with a variable of type "unsigned" and another one of type "int": void f() { unsigned x; int y; ... } The compiler remembers for debugging