similar to: [Bug 1176] Cannot set sticky bits via sftp

On Tue, Jan 16, 2018 at 11:44 AM, Frederik Deweerdt < frederik.deweerdt at gmail.com> wrote: > Hello Kostya, > > I see that master has the same value for kMaxNumChunks, is there > anything in particular that leads you to think i wouldn't run into the > same limit? > No. It's just that I haven't heard anyone else complain recently. If you have a reproducer that

On Wed, Jan 24, 2018 at 12:10 PM, Frederik Deweerdt < frederik.deweerdt at gmail.com> wrote: > On Wed, Jan 24, 2018 at 11:30 AM, Kostya Serebryany <kcc at google.com> > wrote: > > +Aleksey, who has been dealing with the allocator recently. > > > > If you have a "((idx)) < ((kMaxNumChunks))" (0x40000, 0x40000) > > check failure, it means that

Hello, On Wed, Jan 24, 2018 at 4:22 PM, Kostya Serebryany <kcc at google.com> wrote: > > > On Wed, Jan 24, 2018 at 12:10 PM, Frederik Deweerdt > <frederik.deweerdt at gmail.com> wrote: [...] >> >> > If yes, yea, I guess we need to bump kMaxNumChunks >> > >> > >> I'll increase the limit to 2^19 for our build, and I'll report

https://bugzilla.mindrot.org/show_bug.cgi?id=1310 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |djm at mindrot.org Blocks| |1452 --- Comment #3 from Damien Miller

+Aleksey, who has been dealing with the allocator recently. If you have a "((idx)) < ((kMaxNumChunks))" (0x40000, 0x40000) check failure, it means that you've allocated (and did not deallocate) 2^18 large heap regions, each *at least* (2^17+1) bytes. This means, that you have live large heap chunks of 2^35 bytes (or more) in total, which is 32Gb. Does this sound correct? If yes,

Hello Kostya, I see that master has the same value for kMaxNumChunks, is there anything in particular that leads you to think i wouldn't run into the same limit? Thanks, Frederik On Tue, Jan 16, 2018 at 11:23 AM, Kostya Serebryany <kcc at google.com> wrote: > llvm 3.9 seems pretty old. > Does this happen with trunk? > > On Thu, Jan 11, 2018 at 11:20 AM, Frederik Deweerdt

llvm 3.9 seems pretty old. Does this happen with trunk? On Thu, Jan 11, 2018 at 11:20 AM, Frederik Deweerdt via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello, > > We've had a build that hit the following assert: > AddressSanitizer CHECK failed: > /var/lib/jenkins/jenkins/workspace/fst-clang/local/src/ > llvm/llvm-3.9.0.src/projects/compiler-rt/lib/asan/../

https://bugzilla.samba.org/show_bug.cgi?id=11027 Bug ID: 11027 Summary: Sticky bit not set when using --chmod=D+t alone, without --perms Product: rsync Version: 3.0.9 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: core Assignee:

https://bugzilla.mindrot.org/show_bug.cgi?id=1436 Summary: scp -p does not preserve sticky bit (01000) Classification: Unclassified Product: Portable OpenSSH Version: 4.7p1 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: scp AssignedTo: bitbucket at

I've set "force directory mode = 1775" in smb.conf, but when I make directories in a share through network neighborhood, I end up with 0775, i.e. user has rwx, group rwx, others rx. The sticky bit is not getting set. What am I doing wrong? thanks in advance, Ed Schernau ed@schernau.com Network Architect

http://bugzilla.mindrot.org/show_bug.cgi?id=1229 Summary: No way to set default umask for SFTP server Product: Portable OpenSSH Version: 4.3p2 Platform: Other OS/Version: Mac OS X Status: NEW Severity: enhancement Priority: P2 Component: sftp-server AssignedTo: bitbucket at mindrot.org

http://bugzilla.mindrot.org/show_bug.cgi?id=1229 ------- Comment #2 from hans at parse.nl 2006-11-09 20:52 ------- I think there's a bunch of Gentoo users including me that are interested in this feature aswell, now that the Gentoo core system packages team decided to ditch the sftplogging (http://sftplogging.sourceforge.net/) features of the openssh ebuild. See my ticket at

On Wed, Jan 24, 2018 at 11:30 AM, Kostya Serebryany <kcc at google.com> wrote: > +Aleksey, who has been dealing with the allocator recently. > > If you have a "((idx)) < ((kMaxNumChunks))" (0x40000, 0x40000) > check failure, it means that you've allocated (and did not deallocate) 2^18 > large heap regions, each *at least* (2^17+1) bytes. > This means, that

https://bugzilla.mindrot.org/show_bug.cgi?id=3201 Bug ID: 3201 Summary: provide an option to use sftp instead of ssh 'exec sh -c ?' for installing ssh-keys via ssh-copy-id Product: Portable OpenSSH Version: -current Hardware: All OS: All Status: NEW Severity: enhancement

Hi, I have an Ubuntu Linux server where I use Sticky Bits to help enforce specific permissions on Samba shares: -- Each Samba share is associated with a unique Linux group -- Only members of the group can access the share -- All members of the group can create new files and directories in the share -- SGID is set on all directories. -- The "creator" of any new file will be the

https://bugzilla.mindrot.org/show_bug.cgi?id=3787 Bug ID: 3787 Summary: Files with a creation date later than January 19, 2038 are not displayed in 32-bit sftp Product: Portable OpenSSH Version: 9.9p1 Hardware: amd64 OS: Linux Status: NEW Severity: minor Priority: P5

Hello, We've had a build that hit the following assert: AddressSanitizer CHECK failed: /var/lib/jenkins/jenkins/workspace/fst-clang/local/src/llvm/llvm-3.9.0.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator.h:1078 "((idx)) < ((kMaxNumChunks))" (0x40000, 0x40000) Increasing the limit and recompiling seems like the obvious workaround, but I'm wondering

http://bugzilla.mindrot.org/show_bug.cgi?id=452 Summary: sftp does not abort when commands given via -b fail Product: Portable OpenSSH Version: older versions Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: sftp AssignedTo: openssh-unix-dev at mindrot.org

http://bugzilla.mindrot.org/show_bug.cgi?id=452 ------- Additional Comments From spin at avalon.net 2002-12-06 03:15 ------- Forgot to mention that this is 3.1p1-6 RedHat RPM. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

On Tue, Jan 16, 2018 at 1:38 PM, Kostya Serebryany <kcc at google.com> wrote: >> I see that master has the same value for kMaxNumChunks, is there >> anything in particular that leads you to think i wouldn't run into the >> same limit? > > > No. It's just that I haven't heard anyone else complain recently. > If you have a reproducer that works on