similar to: (--delay-updates and --partial) re-hashing the already downloaded files?

https://bugzilla.samba.org/show_bug.cgi?id=10448 Summary: Please include the --ignore-case patch by default Product: rsync Version: 3.1.0 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: core AssignedTo: wayned at samba.org ReportedBy: me at

tested with 3.07 and 3.1 with --ignore-case patch applied cd /tmp mkdir -p a/b/c/d/e/f mkdir -p A/b/C/D/e/F add some files to a/b/c/d/e/f/ rsync -r --ignore-case a/ A/ >> creates b/c/d/e/f/<files> Why is it not ignoring case? I expect it to add all files in 'f' to 'F' -------------- next part -------------- An HTML attachment was scrubbed... URL:

In case you are interested, https://wiki.dovecot.org/HowTo/ConvertPasswordSchemes By the way, I am bit sceptical that CRYPT-SHA512 is less secure than PBKDF2. CRYPT-SHA512 is not "just" SHA512(salt||password), it does at least 1000 rounds of hashing in similar way as PBKDF2 does. So, what is your reasoning for claiming that PBKDF2 is much secure than CRYPT-SHA512? Also, if you look

Thank you for your reply. It's not that simple, though. Just because some core algorithms are standardised and should be compatible doesn't mean their use in different implementations leads to interoperable data. The key point here seems to be that Dovecot just supports SHA-1 with PBKDF2, not SHA-256. So I'm out of luck here. The different formats are no longer relevant then.

https://bugzilla.samba.org/show_bug.cgi?id=10522 Summary: --detect-renamed patch is causing deletions as if a 'delete flag' was supplied, when none have been Product: rsync Version: 3.1.1 Platform: x86 OS/Version: All Status: NEW Severity: normal Priority: P5 Component: core

Hi, /media/clec1enextsanstampon/gigamopourcdas4/ contains an old copy of files of /media/mo. I'm updating with "cd /media/clec1enextsanstampon/ && rsync --backup --backup-dir=/media/clec1enextsanstampon/elementssupprimesdepourcdas4/ --del -hPrStvXz --progress /media/mo/ /media/clec1enextsanstampon/gigamopourcdas4/" But unmodified and already in place files in

https://bugzilla.samba.org/show_bug.cgi?id=10552 Summary: Sender checksum calculation significantly slower with compression enabled Product: rsync Version: 3.1.1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at

Hello, I'm setting up a new server and, again, seek for a decently secure (from a security specialist's POV) way to store and verify user passwords in a database. Additionally now, GDPR requires me to use a solid state-of-the-art solution. My OS is Ubuntu 20.04, Dovecot version 2.3.7, database backend with PostgreSQL 12. Obviously, storing the plaintext password is a terrible idea.

On 6/29/23 16:31, Stephane Ascoet via rsync wrote: > Kevin Korb <kmk at sanitarium.net> le 29/06/2023 04:52: >> --itemize-changes will cause rsync to tell you what it thinks is > > Hi, thank you so much! Today I used a little different way of doing it, > and another computer, and the behaviour is the same. It seems that the > reason is a different timestamp. So the

dovecot 2.3.13 Hi, I'm looking for a way to make director use a user at domain that is returned by the database for hashing but actually send the original user at domain in the proxied request. I cannot seem to find a way. I can change the name used for hashing by just returning a different user from the db. but that user is also the one that is send in the proxied request. this is

I'm trying to understand the method dispatch in objc_MsgSend. At some point during compilation, ascii selectors are hashed into integer SEL's. Is this hash somehow guaranteed to be unique? If so, how? If not, how are collisions handled? Is this hashing done during the link phase? Any insights/pointers to the code/documentation related to this hashing would be greatly appreciated.

The MKsetup() in unique.c throws an error if the vector to be hashed is longer than (2^32)/8: if(n < 0 || n > 536870912) /* protect against overflow to -ve */ error(_("length %d is too large for hashing"), n); I occasionally work with vectors longer than this on 64-bit builds. Would it be too much to ask that R can take advantage of all 64 bits for hashing when

Hello, I'm doing some analysis on a rather large data set. In this case, some simple commands are failing. For example, this one: > x$eventtype <- factor(x$eventtype) Error in unique.default(x) : length 1093574297 is too large for hashing ...I think this is a bug, because "hashing" should not be required for the "factor" function. Am I right? The whole column

Hi, From v3.0.0 onwards the hash function implemented by Rsync was changed from MD4 to MD5 (http://rsync.samba.org/ftp/rsync/src/rsync-3.0.0-NEWS). My understanding is that MD5 is a more secure, slower version of MD4 but I am not convinced that the added security of MD5 would alone have merited the change from MD4 (particularly since MD4 is ~30% faster than MD5). I wonder if I am missing other

Hi, just in case some ipvs knowledgable people read this... I tried to find some info on ipvs destination hashing on the net but did not find anything... Right now we have a basic direct routing round-robin keepalived configuration: abc.example.com (a.b.c.d) => LVS ( round-robin ) => server_[1..n] with IP[1..n]. If we use the dh option, on what would the hashing be done? I saw some

On Fri, Feb 17, 2012 at 3:59 AM, Chandler Carruth<chandlerc at google.com> wrote: > On Tue, Feb 14, 2012 at 2:44 AM, Chris Lattner<clattner at apple.com <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>> wrote: > > >/ I'm contradicting my stance above about not caring about the > />/ implementation :), but is MurmurHash a good hash for string data?

On Feb 28, 2012, at 6:34 AM, Chandler Carruth wrote: > Howard, high-level feedback from you would be particularly appreciated as I would love to contribute this to libc++ when the time is right. Does the enclosed implementation implement this part of N3333: http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2012/n3333.html#per.process.seed ? That to me seems like potentially the most

Hi, I struggle with directory hashing. I want something like this: /srv/mail/c/cf37a8dff5e360927ba10ab2 The final folder is simpel, as it is: %{sha256;truncate=96:user} But how do I get a first level from sha256? Unfortunately, the truncate option aligns only full 8bit and does not divide into low and high nibbles. How can I express this for sha256? in MD5 this would be %1Mu Many thanks in

Is there any way to disable the header hashing in dsync? I'm doing a one-time migration to Dovecot using imapc. The FETCHes for Date & Message-ID take a non-trivial amount of time and it's not clear to me if they have a function for a one-time migration. -- Richard

On 13 February 2012 00:59, Talin <viridia at gmail.com> wrote: > Here's my latest version of Hashing.h, which I propose to add to llvm/ADT. > Comments welcome and encouraged. > /// Adapted from MurmurHash2 by Austin Appleby Just out of curiosity, why not MurmurHash3 ? This page seems to suggest that #2 has some flaw, and #3 is better all round: