[GitHub] [commons-math] bhawna94 edited a comment on pull request #146: Simplify if condition
bhawna94 edited a comment on pull request #146: URL: https://github.com/apache/commons-math/pull/146#issuecomment-645163584 @olamy @epugh @jukka @dims @brettporter @asfgit Could you please review the PR and let me know your thoughts This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-math] bhawna94 commented on pull request #146: Simplify if condition
bhawna94 commented on pull request #146: URL: https://github.com/apache/commons-math/pull/146#issuecomment-645163584 @olamy @epugh @jukka Could you please review the PR and let me know your thoughts This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (CRYPTO-148) Releasing Commons Crypto with AArch64 support
[ https://issues.apache.org/jira/browse/CRYPTO-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17138088#comment-17138088 ] odidev commented on CRYPTO-148: --- [~ggregory], commons-crypto team, please let me know if I can help with anything else to get the commons-crypto project released for AArch64. > Releasing Commons Crypto with AArch64 support > - > > Key: CRYPTO-148 > URL: https://issues.apache.org/jira/browse/CRYPTO-148 > Project: Commons Crypto > Issue Type: Task > Components: Build >Affects Versions: 1.1.0 > Environment: Linux, AArch64 >Reporter: odidev >Priority: Major > Labels: Release > Fix For: 1.1.0 > > Attachments: Dockerfile, > build-instructions-apache-commons-crypto.docx, docker-compose.yaml > > > Currently, Commons Crypto 1.0.0 is available in maven's repository which > doesn't have AArch64 support but Commons Crypto 1.1.0 look have AArch64 > support. Can you please let me know if when it is getting released. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CLI-284) Inconsistency in constraints for creating an instance of class Option using builder pattern or constructor
[
https://issues.apache.org/jira/browse/CLI-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17138011#comment-17138011
]
chenshuming commented on CLI-284:
-
[~fury]
+1, agree.
Option instance can have longOpt value null first and set real value later.
The check should in Options.addOption(Option) because it means we think Option
instance is set up ready.
But if we add a check in Options.addOption(Option) , we want to throw a
exception when check fail. That may break the binary compatibility.
> Inconsistency in constraints for creating an instance of class Option using
> builder pattern or constructor
> --
>
> Key: CLI-284
> URL: https://issues.apache.org/jira/browse/CLI-284
> Project: Commons CLI
> Issue Type: Bug
>Reporter: Dilraj Singh
>Assignee: Bruno P. Kinoshita
>Priority: Major
>
> Builder pattern for creating an instance of class *Option* ensures that at
> least one of the representation (short and long representation) for the
> option is not null. It throws an *IllegalArgumentException* in-case program
> tries to build an instance with both the representations as null. Consider
> the following code snippet for reference.
> {code:java}
> public static void main(String[] args) {
> Option.Builder builder = Option.builder();
> Option op = builder.build();
> }
> {code}
> This piece of code fails with the following exception
> {noformat}
> Exception in thread "main" java.lang.IllegalArgumentException: Either opt or
> longOpt must be specified
> {noformat}
> But if we try to create an instance of Option by calling its constructor, It
> allows the creation with both opt and longOpt for Option as null. Consider
> the following code snippet for reference
> {code:java}
> public static void main(String[] args) {
> Option op = new Option(null, null);
> System.out.format("Short Representation: %s\n" +
> "Long Representation: %s", op.getOpt(),
> op.getLongOpt());
> }
> {code}
> Output:
> {noformat}
> Short Representation: null
> Long Representation: null
> {noformat}
> Calling a method on an instance with both opt and longOpt as null will lead
> to undesired null pointer exception. For example, calling
> {code:java}
> op.getId() {code}
> will throw a null pointer exception, thus violating the method contract.
> So as to fix this we need to make sure that whenever a constructor is invoked
> it has a non-null argument value for at least one of the Option
> representation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (VFS-766) SftpClientFactory hangs at FileSystemManager.resolveFile(...)
[
https://issues.apache.org/jira/browse/VFS-766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17137916#comment-17137916
]
Kevin Hollenshead commented on VFS-766:
---
[~manishbansal8843] I have not started on making changes, so please do. If you
want someone to test it, let me know.
> SftpClientFactory hangs at FileSystemManager.resolveFile(...)
> -
>
> Key: VFS-766
> URL: https://issues.apache.org/jira/browse/VFS-766
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.5.0, 2.6.0
>Reporter: Jasper Teng
>Priority: Critical
>
> Issue: When trying to sftp, it hangs inside
> FileSystemManager.resolveFile(...).
>
> Libs in classpath used for testing:
> * commons-vfs2-2.6.0.jar / commons-vfs2-2.5.0.jar
> * commons-vfs2-jackrabbit2-2.5.0.jar
> * jackrabbit-webdav-2.20.0.jar
>
> Issue Log file (2.5.0 + Server X):
> {noformat}
> 25 Mar, 20:00:37,825 INFO main [SftpClientFactory$JSchLogger.log()]
> [65017ms] Connection established
> 25 Mar, 20:00:38,013 INFO main [SftpClientFactory$JSchLogger.log()]
> [65205ms] Remote version string: SSH-2.0-ProVide
> 25 Mar, 20:00:38,017 INFO main [SftpClientFactory$JSchLogger.log()]
> [65209ms] Local version string: SSH-2.0-JSCH-0.1.52
> ...snip...
> 25 Mar, 20:01:02,802 INFO main [SftpClientFactory$JSchLogger.log()]
> [89994ms] kex: server->client aes128-ctr hmac-md5 none
> 25 Mar, 20:01:02,809 INFO main [SftpClientFactory$JSchLogger.log()]
> [90001ms] kex: client->server aes128-ctr hmac-md5 none
> 25 Mar, 20:01:06,359 INFO main [SftpClientFactory$JSchLogger.log()]
> [93551ms] SSH_MSG_KEXDH_INIT sent
> 25 Mar, 20:01:06,363 INFO main [SftpClientFactory$JSchLogger.log()]
> [93555ms] expecting SSH_MSG_KEXDH_REPLY
> 25 Mar, 20:01:10,410 INFO main [SftpClientFactory$JSchLogger.log()]
> [97602ms] ssh_rsa_verify: signature true
> 25 Mar, 20:01:10,427 WARN main [SftpClientFactory$JSchLogger.log()]
> [97619ms] Permanently added 'mask.mask.mask' (RSA) to the list of known hosts.
> 25 Mar, 20:01:10,438 INFO main [SftpClientFactory$JSchLogger.log()]
> [97630ms] SSH_MSG_NEWKEYS sent
> 25 Mar, 20:01:10,625 INFO main [SftpClientFactory$JSchLogger.log()]
> [97817ms] SSH_MSG_NEWKEYS received
> 25 Mar, 20:01:10,709 INFO main [SftpClientFactory$JSchLogger.log()]
> [97901ms] SSH_MSG_SERVICE_REQUEST sent
> 25 Mar, 20:01:10,897 INFO main [SftpClientFactory$JSchLogger.log()]
> [98089ms] SSH_MSG_SERVICE_ACCEPT received
> 25 Mar, 20:01:11,098 INFO main [SftpClientFactory$JSchLogger.log()]
> [98290ms] Authentications that can continue:
> publickey,keyboard-interactive,password
> 25 Mar, 20:01:11,102 INFO main [SftpClientFactory$JSchLogger.log()]
> [98294ms] Next authentication method: publickey
> 25 Mar, 20:01:11,114 INFO main [SftpClientFactory$JSchLogger.log()]
> [98306ms] Authentications that can continue: password
> 25 Mar, 20:01:11,119 INFO main [SftpClientFactory$JSchLogger.log()]
> [98311ms] Next authentication method: password
> 25 Mar, 20:01:11,735 INFO main [SftpClientFactory$JSchLogger.log()]
> [98927ms] Authentication succeeded (password).{noformat}
>
> Issue Log file (2.6.0 + Server X):
> {noformat}
> 26 Mar, 09:42:07,781 INFO main [SftpClientFactory$JSchLogger.log()]
> [20400ms] Connection established
> 26 Mar, 09:42:07,971 INFO main [SftpClientFactory$JSchLogger.log()]
> [20590ms] Remote version string: SSH-2.0-ProVide
> 26 Mar, 09:42:07,975 INFO main [SftpClientFactory$JSchLogger.log()]
> [20594ms] Local version string: SSH-2.0-JSCH-0.1.52
> ...snip...
> 26 Mar, 09:42:33,250 INFO main [SftpClientFactory$JSchLogger.log()]
> [45869ms] kex: server->client aes128-ctr hmac-md5 none
> 26 Mar, 09:42:33,258 INFO main [SftpClientFactory$JSchLogger.log()]
> [45877ms] kex: client->server aes128-ctr hmac-md5 none
> 26 Mar, 09:42:36,710 INFO main [SftpClientFactory$JSchLogger.log()]
> [49329ms] SSH_MSG_KEXDH_INIT sent
> 26 Mar, 09:42:36,716 INFO main [SftpClientFactory$JSchLogger.log()]
> [49335ms] expecting SSH_MSG_KEXDH_REPLY
> 26 Mar, 09:42:40,635 INFO main [SftpClientFactory$JSchLogger.log()]
> [53254ms] ssh_rsa_verify: signature true
> 26 Mar, 09:42:40,653 INFO main [SftpClientFactory$JSchLogger.log()]
> [53272ms] Host 'mask.mask.mask' is known and matches the RSA host key
> 26 Mar, 09:42:40,660 INFO main [SftpClientFactory$JSchLogger.log()]
> [53279ms] SSH_MSG_NEWKEYS sent
> 26 Mar, 09:42:40,845 INFO main [SftpClientFactory$JSchLogger.log()]
> [53464ms] SSH_MSG_NEWKEYS received
> 26 Mar, 09:42:40,953 INFO main [SftpClientFactory$JSchLogger.log()]
> [53572ms] SSH_MSG_SERVICE_REQUEST sent
> 26 Mar, 09:42:41,153 INFO main [SftpClientFactory$JSchLogger.log()]
> [53772ms] SSH_MSG_SERVICE_ACCEPT received
> 26 Mar, 09:42:41,356 INFO main [SftpClientFactory$JSchLogger.log()]
> [53975ms] Authen
[jira] [Comment Edited] (FILEUPLOAD-304) value lines are terminated CR LF instead of just LF
[
https://issues.apache.org/jira/browse/FILEUPLOAD-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17137842#comment-17137842
]
Jochen Wiedmann edited comment on FILEUPLOAD-304 at 6/16/20, 6:33 PM:
--
What justifies your claim, that "if FileUpload is not involved: lines of text
are terminated by LF"?
was (Author: joc...@apache.org):
What justifies your claim, that "if FileUpload is not involved: lines of text
are terminated by LF"?
> value lines are terminated CR LF instead of just LF
> --
>
> Key: FILEUPLOAD-304
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-304
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Paul Pogonyshev
>Priority: Minor
>
> Steps to reproduce:
> * create a form with text area
> * submit some multiline text through it
> If the form doesn't contain any file inputs, i.e. if FileUpload is not
> involved: lines of text are terminated by LF.
> However, if there is a file input and you get the value using
> FileItem.getString ("UTF-8"), text lines are terminated by CR LF.
> As a result, CR LF can get into database. Additionally, database column size
> limit can be exceeded even if you check for this on the client side (client
> side always sees LF, on server side it gets transformed to CR LF, so text
> length is increased).
> I guess the same applies to any multiline text you submit within a multipart
> form, e.g. if you set in JS: after arriving to the server, all LF get
> transformed to CR LF.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FILEUPLOAD-304) value lines are terminated CR LF instead of just LF
[
https://issues.apache.org/jira/browse/FILEUPLOAD-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17137842#comment-17137842
]
Jochen Wiedmann commented on FILEUPLOAD-304:
What justifies your claim, that "if FileUpload is not involved: lines of text
are terminated by LF"?
> value lines are terminated CR LF instead of just LF
> --
>
> Key: FILEUPLOAD-304
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-304
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Paul Pogonyshev
>Priority: Minor
>
> Steps to reproduce:
> * create a form with text area
> * submit some multiline text through it
> If the form doesn't contain any file inputs, i.e. if FileUpload is not
> involved: lines of text are terminated by LF.
> However, if there is a file input and you get the value using
> FileItem.getString ("UTF-8"), text lines are terminated by CR LF.
> As a result, CR LF can get into database. Additionally, database column size
> limit can be exceeded even if you check for this on the client side (client
> side always sees LF, on server side it gets transformed to CR LF, so text
> length is increased).
> I guess the same applies to any multiline text you submit within a multipart
> form, e.g. if you set in JS: after arriving to the server, all LF get
> transformed to CR LF.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (COMPRESS-538) ZipEntry created using ZipArchiveOutputStream(File) constructor adds 'ZIP64 Extended Information Extra Field' even when zip64 is not required.
[
https://issues.apache.org/jira/browse/COMPRESS-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pritesh updated COMPRESS-538:
-
Affects Version/s: 1.9
1.20
> ZipEntry created using ZipArchiveOutputStream(File) constructor adds 'ZIP64
> Extended Information Extra Field' even when zip64 is not required.
> --
>
> Key: COMPRESS-538
> URL: https://issues.apache.org/jira/browse/COMPRESS-538
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.8, 1.9, 1.20
>Reporter: Pritesh
>Assignee: Peter Lee
>Priority: Major
>
> When creating a zip file using
> [ZipArchiveOutputStream(File)|https://commons.apache.org/proper/commons-compress/apidocs/org/apache/commons/compress/archivers/zip/ZipArchiveOutputStream.html#ZipArchiveOutputStream-java.io.File-]
> constructor each entry get an extra `Zip64ExtendedInformationExtraField`
> header which shouldn't be there.
>
> The issue can be reproduced using below code sample
> {code:java}
> public static void main(String[] args) throws IOException {
> // Create file
> final File file = File.createTempFile("apache_", ".zip");
> try ( ZipArchiveOutputStream zos = new ZipArchiveOutputStream(file)) {
> zos.putArchiveEntry(new ZipArchiveEntry("TextFile1.txt"));
> zos.closeArchiveEntry();
> }
> // List Headers File
> final ZipFile zipFile = new ZipFile(file);
> final Enumeration entries =
> zipFile.getEntries();
> while (entries.hasMoreElements()) {
> final ZipArchiveEntry entry = entries.nextElement();
> for (ZipExtraField zipExtraField : entry.getExtraFields()) {
> System.out.println("EntryName:" + entry.getName() + " Header:
> "+ zipExtraField.getHeaderId().getValue()); // Header shouldn't be present.
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (FILEUPLOAD-304) value lines are terminated CR LF instead of just LF
Paul Pogonyshev created FILEUPLOAD-304:
--
Summary: value lines are terminated CR LF instead of
just LF
Key: FILEUPLOAD-304
URL: https://issues.apache.org/jira/browse/FILEUPLOAD-304
Project: Commons FileUpload
Issue Type: Bug
Affects Versions: 1.4
Reporter: Paul Pogonyshev
Steps to reproduce:
* create a form with text area
* submit some multiline text through it
If the form doesn't contain any file inputs, i.e. if FileUpload is not
involved: lines of text are terminated by LF.
However, if there is a file input and you get the value using
FileItem.getString ("UTF-8"), text lines are terminated by CR LF.
As a result, CR LF can get into database. Additionally, database column size
limit can be exceeded even if you check for this on the client side (client
side always sees LF, on server side it gets transformed to CR LF, so text
length is increased).
I guess the same applies to any multiline text you submit within a multipart
form, e.g. if you set in JS: after arriving to the server, all LF get
transformed to CR LF.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LANG-1571) Allow to pass Supplier varargs to getIfNull
[ https://issues.apache.org/jira/browse/LANG-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17136617#comment-17136617 ] Gary D. Gregory commented on LANG-1571: --- We are just volunteers here, it takes a while to reply sometimes... ;) > Allow to pass Supplier varargs to getIfNull > --- > > Key: LANG-1571 > URL: https://issues.apache.org/jira/browse/LANG-1571 > Project: Commons Lang > Issue Type: Improvement >Reporter: Yeldos Tanikin >Priority: Major > > change > public static T getIfNull(final T object, final Supplier > defaultSupplier) > to > public static T getIfNull(final T object, final Supplier... suppliers) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-parent] sebbASF closed pull request #3: Fix commons site deployment
sebbASF closed pull request #3: URL: https://github.com/apache/commons-parent/pull/3 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-parent] sebbASF commented on pull request #3: Fix commons site deployment
sebbASF commented on pull request #3: URL: https://github.com/apache/commons-parent/pull/3#issuecomment-644710655 Almost all the Commons components (including IO) now use an artifactID beginning with 'commons' The only exceptions are: bcel bsf crypto-jmh Therefore the PR is not needed This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Deleted] (EMAIL-194) Convert Exchange EDB file into Outlook PST by Using InQuit Software Easy & Safe steps
[ https://issues.apache.org/jira/browse/EMAIL-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov deleted EMAIL-194: - > Convert Exchange EDB file into Outlook PST by Using InQuit Software Easy & > Safe steps > - > > Key: EMAIL-194 > URL: https://issues.apache.org/jira/browse/EMAIL-194 > Project: Commons Email > Issue Type: Bug >Reporter: aaliyah bailey >Priority: Major > > InQuit *EDB to PST Converter* is high in demand and it already has a great > impact on the user's mind, it makes easy to convert EDB files into PST files > and you can keep your Outlook safe and secure by using this EDB recovery tool. > > Exchange server is a dominating email client in the world for business > communication, ranging from small and medium to large organizations. It > provides fast communication and stores that data in EDB format including > Emails, contact, calendar, journal task, drafts, notes, deleted items, and > attachment, etc. You can access it in Offline Mode and always whenever it > gets online, it synchronized automatically with Exchange Server. Any size of > files you can convert using this tool and the best thing is that installation > of Microsoft Outlook is not mandatory for the working of this EDB files to > PST files converter, always it does not matter whether your files are > password protected or not. > > The advantage of using InQuit EDB to PST Conversion is that you will get the > full package of features that take you out of the problem of Outlook > corruption. It supports all the MS Outlook versions 98, 2000, 2002, 2003, > 2007, 2010, 2013, and 2019. And all the supporting formats like PST, EMLX, > EML, vCard, vCal, MBOX, and MSG. you can also use the cloud-based application > like Office 365 & Live Exchange Server. until it works well you enjoy > hassle-free work and once it gets corrupted or damaged due to several reasons > everything become inaccessible, you will not be able to receive and send an > email while it is not getting corrected. > > It is essential to know about the conversion process of this efficient tool. > Although it is very simple to use but still step by step process helps to get > the work done more smoothly and perfectly. > > Step 1: Install the *[InQuit EDB to PST > Software|https://www.inquitsoftware.com/en/pages/edb-to-pst-converter.html]* > from the official website. > Step 2: Select Corrupt EDB file to convert them into PST File. > Step 3: Preview EDB mailboxes Items and select the mailboxes to export to > PST. > Step 4: Export selected mailboxes or folders to PST. > Step 5: Get the desired result. > > InQuit Software is a well-established name in the field of data recovery > software and also has a great impact on the users' minds, and the reasons > which make this tool incredible are its highly advanced features. > > InQuit EDB Recovery tool is an amazingly designed software that can assure > you the 100% guarantee of your Outlook mailbox data like inbox, outbox, > sent-items, deleted-items, drafts, contacts, calendars, notes (to, cc, bcc, > subject, date and time). Many industries are using MS Outlook email client > for their business communication because it has a great impact on the mind of > the users all over the world. Some of its features are listed below: > > # It supports live Exchange Server 5.0, 5.5, 2000, 2003, 2007, 2010, 2013, > 2016. > # Convert encrypted and password protected files also. > # This EDB files to PST files converter work in the absence of MS Outlook > without any data deficiency. > # Tested on the very large size of the file in the software data laboratory. > # Allows converting single mailboxes as well as multiple mailboxes which > includes an inbox, outbox, sent-items, deleted-items, drafts, contacts, > calendars, notes (to, cc, bcc, subject, date and time). > # Migrate EDB files directly into the Live Exchange server and Office 365. > # To evaluate this tool it provides a free demo version in which the users > will be allowed to access 30 email items from each folder. > # It supports MS Outlook 98, 2000, 2002, 2003, 2007, 2010, 2013, 2016 and > 2019. > *Read more info*: > [https://www.inquitsoftware.com/en/pages/edb-to-pst-converter.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (LANG-1571) Allow to pass Supplier varargs to getIfNull
[ https://issues.apache.org/jira/browse/LANG-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17136534#comment-17136534 ] Yeldos Tanikin commented on LANG-1571: -- Hi [~ggregory] , I wrote the letter for dev list, but didn't get an answer, is that normal that it takes more than one day? Did I do correctly that wrote to dev list? What should I do to implement the task? I just realized that I should have created at least after discussing via email > Allow to pass Supplier varargs to getIfNull > --- > > Key: LANG-1571 > URL: https://issues.apache.org/jira/browse/LANG-1571 > Project: Commons Lang > Issue Type: Improvement >Reporter: Yeldos Tanikin >Priority: Major > > change > public static T getIfNull(final T object, final Supplier > defaultSupplier) > to > public static T getIfNull(final T object, final Supplier... suppliers) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (EMAIL-194) Convert Exchange EDB file into Outlook PST by Using InQuit Software Easy & Safe steps
[ https://issues.apache.org/jira/browse/EMAIL-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] aaliyah bailey updated EMAIL-194: - Description: InQuit *EDB to PST Converter* is high in demand and it already has a great impact on the user's mind, it makes easy to convert EDB files into PST files and you can keep your Outlook safe and secure by using this EDB recovery tool. Exchange server is a dominating email client in the world for business communication, ranging from small and medium to large organizations. It provides fast communication and stores that data in EDB format including Emails, contact, calendar, journal task, drafts, notes, deleted items, and attachment, etc. You can access it in Offline Mode and always whenever it gets online, it synchronized automatically with Exchange Server. Any size of files you can convert using this tool and the best thing is that installation of Microsoft Outlook is not mandatory for the working of this EDB files to PST files converter, always it does not matter whether your files are password protected or not. The advantage of using InQuit EDB to PST Conversion is that you will get the full package of features that take you out of the problem of Outlook corruption. It supports all the MS Outlook versions 98, 2000, 2002, 2003, 2007, 2010, 2013, and 2019. And all the supporting formats like PST, EMLX, EML, vCard, vCal, MBOX, and MSG. you can also use the cloud-based application like Office 365 & Live Exchange Server. until it works well you enjoy hassle-free work and once it gets corrupted or damaged due to several reasons everything become inaccessible, you will not be able to receive and send an email while it is not getting corrected. It is essential to know about the conversion process of this efficient tool. Although it is very simple to use but still step by step process helps to get the work done more smoothly and perfectly. Step 1: Install the *[InQuit EDB to PST Software|https://www.inquitsoftware.com/en/pages/edb-to-pst-converter.html]* from the official website. Step 2: Select Corrupt EDB file to convert them into PST File. Step 3: Preview EDB mailboxes Items and select the mailboxes to export to PST. Step 4: Export selected mailboxes or folders to PST. Step 5: Get the desired result. InQuit Software is a well-established name in the field of data recovery software and also has a great impact on the users' minds, and the reasons which make this tool incredible are its highly advanced features. InQuit EDB Recovery tool is an amazingly designed software that can assure you the 100% guarantee of your Outlook mailbox data like inbox, outbox, sent-items, deleted-items, drafts, contacts, calendars, notes (to, cc, bcc, subject, date and time). Many industries are using MS Outlook email client for their business communication because it has a great impact on the mind of the users all over the world. Some of its features are listed below: # It supports live Exchange Server 5.0, 5.5, 2000, 2003, 2007, 2010, 2013, 2016. # Convert encrypted and password protected files also. # This EDB files to PST files converter work in the absence of MS Outlook without any data deficiency. # Tested on the very large size of the file in the software data laboratory. # Allows converting single mailboxes as well as multiple mailboxes which includes an inbox, outbox, sent-items, deleted-items, drafts, contacts, calendars, notes (to, cc, bcc, subject, date and time). # Migrate EDB files directly into the Live Exchange server and Office 365. # To evaluate this tool it provides a free demo version in which the users will be allowed to access 30 email items from each folder. # It supports MS Outlook 98, 2000, 2002, 2003, 2007, 2010, 2013, 2016 and 2019. *Read more info*: [https://www.inquitsoftware.com/en/pages/edb-to-pst-converter.html] was: InQuit *EDB to PST converter* is high in demand and it already has a great impact on the user's mind, it makes easy to convert EDB files into PST files and you can keep your Outlook safe and secure by using this EDB recovery tool. Exchange server is a dominating email client in the world for business communication, ranging from small and medium to large organizations. It provides fast communication and stores that data in EDB format including Emails, contact, calendar, journal task, drafts, notes, deleted items, and attachment, etc. You can access it in Offline Mode and always whenever it gets online, it synchronized automatically with Exchange Server. Any size of files you can convert using this tool and the best thing is that installation of Microsoft Outlook is not mandatory for the working of this EDB files to PST files converter, always it does not matter whether your files are password protected or not. The advantage of using InQui
[jira] [Created] (EMAIL-194) Convert Exchange EDB file into Outlook PST by Using InQuit Software Easy & Safe steps
aaliyah bailey created EMAIL-194: Summary: Convert Exchange EDB file into Outlook PST by Using InQuit Software Easy & Safe steps Key: EMAIL-194 URL: https://issues.apache.org/jira/browse/EMAIL-194 Project: Commons Email Issue Type: Bug Reporter: aaliyah bailey InQuit *EDB to PST converter* is high in demand and it already has a great impact on the user's mind, it makes easy to convert EDB files into PST files and you can keep your Outlook safe and secure by using this EDB recovery tool. Exchange server is a dominating email client in the world for business communication, ranging from small and medium to large organizations. It provides fast communication and stores that data in EDB format including Emails, contact, calendar, journal task, drafts, notes, deleted items, and attachment, etc. You can access it in Offline Mode and always whenever it gets online, it synchronized automatically with Exchange Server. Any size of files you can convert using this tool and the best thing is that installation of Microsoft Outlook is not mandatory for the working of this EDB files to PST files converter, always it does not matter whether your files are password protected or not. The advantage of using InQuit EDB to PST Converter is that you will get the full package of features that take you out of the problem of Outlook corruption. It supports all the MS Outlook versions 98, 2000, 2002, 2003, 2007, 2010, 2013, and 2019. And all the supporting formats like PST, EMLX, EML, vCard, vCal, MBOX, and MSG. you can also use the cloud-based application like Office 365 & Live Exchange Server. until it works well you enjoy hassle-free work and once it gets corrupted or damaged due to several reasons everything become inaccessible, you will not be able to receive and send an email while it is not getting corrected. It is essential to know about the conversion process of this efficient tool. Although it is very simple to use but still step by step process helps to get the work done more smoothly and perfectly. Step 1: Install the *InQuit EDB to PST Software* from the official website. Step 2: Select Corrupt EDB file to convert them into PST File. Step 3: Preview EDB mailboxes Items and select the mailboxes to export to PST. Step 4: Export selected mailboxes or folders to PST. Step 5: Get the desired result. InQuit Software is a well-established name in the field of data recovery software and also has a great impact on the users' minds, and the reasons which make this tool incredible are its highly advanced features. InQuit EDB to PST Converter is an amazingly designed software that can assure you the 100% guarantee of your Outlook mailbox data like inbox, outbox, sent-items, deleted-items, drafts, contacts, calendars, notes (to, cc, bcc, subject, date and time). Many industries are using MS Outlook email client for their business communication because it has a great impact on the mind of the users all over the world. Some of its features are listed below: # It supports live Exchange Server 5.0, 5.5, 2000, 2003, 2007, 2010, 2013, 2016. # Convert encrypted and password protected files also. # This EDB files to PST files converter work in the absence of MS Outlook without any data deficiency. # Tested on the very large size of the file in the software data laboratory. # Allows converting single mailboxes as well as multiple mailboxes which includes an inbox, outbox, sent-items, deleted-items, drafts, contacts, calendars, notes (to, cc, bcc, subject, date and time). # Migrate EDB files directly into the Live Exchange server and Office 365. # To evaluate this tool it provides a free demo version in which the users will be allowed to access 30 email items from each folder. # It supports MS Outlook 98, 2000, 2002, 2003, 2007, 2010, 2013, 2016 and 2019. *Read more info:* [*https://www.inquitsoftware.com/en/pages/edb-to-pst-converter.html*] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CLI-300) DefaultParser fails to parse token "-S=V" if short option is longer than 1 char
[
https://issues.apache.org/jira/browse/CLI-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17136466#comment-17136466
]
chenshuming commented on CLI-300:
-
I notice the way to build option in description is :
{code:java}
Option option = Option.builder("foo").hasArg().build();
{code}
Maybe you can try this ,it will work in my test:
{code:java}
Option option = Option.builder("f").longOpt("foo").hasArg().build();
{code}
> DefaultParser fails to parse token "-S=V" if short option is longer than 1
> char
> ---
>
> Key: CLI-300
> URL: https://issues.apache.org/jira/browse/CLI-300
> Project: Commons CLI
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.4
> Environment: Windows 10, Java 11
>Reporter: Balz Guenat
>Priority: Major
>
> Assuming there is a short option with {{foo}} with one argument. Trying to
> parse a token like {{-foo=bar}} results in an UnrecognizedOptionException.
> The same scenario works fine if the short option is only one char long.
> The reason is an if-statement in {{DefaultParser.handleShortAndLongOption()}}
> (line 543 in v1.4), which checks {{opt.length() == 1}} before checking if the
> option exists. IMO, this check should instead be {{isShortOption(opt)}}.
> The below code demonstrates the issue.
> {{Options options = new Options();}}
> {{Option option = Option.builder("foo").hasArg().build();}}
> {{options.addOption(option);}}
> {{String[] args = new String[] \{"-foo=bar"};}}
> {{DefaultParser parser = new DefaultParser();}}
> {{CommandLine cmdLine = parser.parse(options, args);}}
> {{assertEquals("bar", cmdLine.getOptionValue("foo"));}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-538) ZipEntry created using ZipArchiveOutputStream(File) constructor adds 'ZIP64 Extended Information Extra Field' even when zip64 is not required.
[
https://issues.apache.org/jira/browse/COMPRESS-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17136447#comment-17136447
]
Pritesh commented on COMPRESS-538:
--
Yes, specifying the file size does fix the issue but aren't we trying to remove
ZIP64 extra at
[ZipArchiveOutputStream#704?|http://commons.apache.org/proper/commons-compress/javadocs/api-1.18/src-html/org/apache/commons/compress/archivers/zip/ZipArchiveOutputStream.html#704]
for the 3rd case? In-fact, it does removes the field from ZipArchiveEntry's
extraFields but fails to update ZipEntry's extra.
> ZipEntry created using ZipArchiveOutputStream(File) constructor adds 'ZIP64
> Extended Information Extra Field' even when zip64 is not required.
> --
>
> Key: COMPRESS-538
> URL: https://issues.apache.org/jira/browse/COMPRESS-538
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.8
>Reporter: Pritesh
>Assignee: Peter Lee
>Priority: Major
>
> When creating a zip file using
> [ZipArchiveOutputStream(File)|https://commons.apache.org/proper/commons-compress/apidocs/org/apache/commons/compress/archivers/zip/ZipArchiveOutputStream.html#ZipArchiveOutputStream-java.io.File-]
> constructor each entry get an extra `Zip64ExtendedInformationExtraField`
> header which shouldn't be there.
>
> The issue can be reproduced using below code sample
> {code:java}
> public static void main(String[] args) throws IOException {
> // Create file
> final File file = File.createTempFile("apache_", ".zip");
> try ( ZipArchiveOutputStream zos = new ZipArchiveOutputStream(file)) {
> zos.putArchiveEntry(new ZipArchiveEntry("TextFile1.txt"));
> zos.closeArchiveEntry();
> }
> // List Headers File
> final ZipFile zipFile = new ZipFile(file);
> final Enumeration entries =
> zipFile.getEntries();
> while (entries.hasMoreElements()) {
> final ZipArchiveEntry entry = entries.nextElement();
> for (ZipExtraField zipExtraField : entry.getExtraFields()) {
> System.out.println("EntryName:" + entry.getName() + " Header:
> "+ zipExtraField.getHeaderId().getValue()); // Header shouldn't be present.
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (COMPRESS-538) ZipEntry created using ZipArchiveOutputStream(File) constructor adds 'ZIP64 Extended Information Extra Field' even when zip64 is not required.
[
https://issues.apache.org/jira/browse/COMPRESS-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Lee updated COMPRESS-538:
---
Assignee: Peter Lee
> ZipEntry created using ZipArchiveOutputStream(File) constructor adds 'ZIP64
> Extended Information Extra Field' even when zip64 is not required.
> --
>
> Key: COMPRESS-538
> URL: https://issues.apache.org/jira/browse/COMPRESS-538
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.8
>Reporter: Pritesh
>Assignee: Peter Lee
>Priority: Major
>
> When creating a zip file using
> [ZipArchiveOutputStream(File)|https://commons.apache.org/proper/commons-compress/apidocs/org/apache/commons/compress/archivers/zip/ZipArchiveOutputStream.html#ZipArchiveOutputStream-java.io.File-]
> constructor each entry get an extra `Zip64ExtendedInformationExtraField`
> header which shouldn't be there.
>
> The issue can be reproduced using below code sample
> {code:java}
> public static void main(String[] args) throws IOException {
> // Create file
> final File file = File.createTempFile("apache_", ".zip");
> try ( ZipArchiveOutputStream zos = new ZipArchiveOutputStream(file)) {
> zos.putArchiveEntry(new ZipArchiveEntry("TextFile1.txt"));
> zos.closeArchiveEntry();
> }
> // List Headers File
> final ZipFile zipFile = new ZipFile(file);
> final Enumeration entries =
> zipFile.getEntries();
> while (entries.hasMoreElements()) {
> final ZipArchiveEntry entry = entries.nextElement();
> for (ZipExtraField zipExtraField : entry.getExtraFields()) {
> System.out.println("EntryName:" + entry.getName() + " Header:
> "+ zipExtraField.getHeaderId().getValue()); // Header shouldn't be present.
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-538) ZipEntry created using ZipArchiveOutputStream(File) constructor adds 'ZIP64 Extended Information Extra Field' even when zip64 is not required.
[
https://issues.apache.org/jira/browse/COMPRESS-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17136390#comment-17136390
]
Peter Lee commented on COMPRESS-538:
Commons Compress will add zip64 extra field in the following cases:
1, The Zip64Mode is Zip64Mode.Always : you can modify this by entry.setUnixMode;
2, The uncompressed size or compressed size of the entry is large so we need to
use zip64;
3, The uncompressed size of the entry is unknown and the Zip64Mode is NOT
Zip64Mode.Never : we do not know the entry's uncompressed size, so we add a
zip64 extra here in case of it's too large.
In your particular testcase, you're experiencing the third case I have listed.
You can simply avoid this by specifying the size of the file :
{code:java}
@Test
public void testExtra() throws IOException {
// Create file
final File file = File.createTempFile("apache_", ".zip");
try ( ZipArchiveOutputStream zos = new ZipArchiveOutputStream(file)) {
ZipArchiveEntry entry = new ZipArchiveEntry("TextFile1.txt");
entry.setSize(0);
zos.putArchiveEntry(entry);
zos.closeArchiveEntry();
}
// List Headers File
final ZipFile zipFile = new ZipFile(file);
final Enumeration entries = zipFile.getEntries();
while (entries.hasMoreElements()) {
final ZipArchiveEntry entry = entries.nextElement();
for (ZipExtraField zipExtraField : entry.getExtraFields()) {
System.out.println("EntryName:" + entry.getName() + " Header: "+
zipExtraField.getHeaderId().getValue()); // Header shouldn't be present.
}
}
}
{code}
BTW : the affected version you set is 1.8 but the latest release of Commons
Compress is 1.20. I'm only testing this in 1.20.
> ZipEntry created using ZipArchiveOutputStream(File) constructor adds 'ZIP64
> Extended Information Extra Field' even when zip64 is not required.
> --
>
> Key: COMPRESS-538
> URL: https://issues.apache.org/jira/browse/COMPRESS-538
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.8
>Reporter: Pritesh
>Priority: Major
>
> When creating a zip file using
> [ZipArchiveOutputStream(File)|https://commons.apache.org/proper/commons-compress/apidocs/org/apache/commons/compress/archivers/zip/ZipArchiveOutputStream.html#ZipArchiveOutputStream-java.io.File-]
> constructor each entry get an extra `Zip64ExtendedInformationExtraField`
> header which shouldn't be there.
>
> The issue can be reproduced using below code sample
> {code:java}
> public static void main(String[] args) throws IOException {
> // Create file
> final File file = File.createTempFile("apache_", ".zip");
> try ( ZipArchiveOutputStream zos = new ZipArchiveOutputStream(file)) {
> zos.putArchiveEntry(new ZipArchiveEntry("TextFile1.txt"));
> zos.closeArchiveEntry();
> }
> // List Headers File
> final ZipFile zipFile = new ZipFile(file);
> final Enumeration entries =
> zipFile.getEntries();
> while (entries.hasMoreElements()) {
> final ZipArchiveEntry entry = entries.nextElement();
> for (ZipExtraField zipExtraField : entry.getExtraFields()) {
> System.out.println("EntryName:" + entry.getName() + " Header:
> "+ zipExtraField.getHeaderId().getValue()); // Header shouldn't be present.
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
