<?xml version="1.0" encoding="utf-8"?>
<feed xml:lang="en" xmlns="http://www.w3.org/2005/Atom"><title>Recent changes to patches</title><link href="https://sourceforge.net/p/j-ftp/patches/" rel="alternate"/><link href="https://sourceforge.net/p/j-ftp/patches/feed.atom" rel="self"/><id>https://sourceforge.net/p/j-ftp/patches/</id><updated>2012-04-06T00:25:11Z</updated><subtitle>Recent changes to patches</subtitle><entry><title>Patch for Bug# 3511543</title><link href="https://sourceforge.net/p/j-ftp/patches/8/" rel="alternate"/><published>2012-04-06T00:25:11Z</published><updated>2012-04-06T00:25:11Z</updated><author><name>Daniel</name><uri>https://sourceforge.net/u/reichert-d/</uri></author><id>https://sourceforge.net839c7ba9b609da4adcc101d0cf07709ce888ec87</id><summary type="html">&lt;div class="markdown_content"&gt;&lt;p&gt;I corrected the issue with opening files by re-writing the runCommand method in UIUtils.java.  The new version of this method requires importing java.awt.Desktop, java.io.File, and java.io.IOException.  I used the Java Desktop class so that the file will be opened with the default application set by the operating system.  I have tested this in Windows 7 and Mac OSX 10.6.  This method also works for opening images so commenting out the lines that handle images in LocalDir.java (approx lines 1428-1435) will have images open up in the appropriate application instead of trying to open them natively in Java.&lt;/p&gt;&lt;/div&gt;</summary></entry><entry><title>Stop Metouia lnf from loading more than once</title><link href="https://sourceforge.net/p/j-ftp/patches/7/" rel="alternate"/><published>2003-09-16T00:53:41Z</published><updated>2003-09-16T00:53:41Z</updated><author><name>David Walluck</name><uri>https://sourceforge.net/u/walluck/</uri></author><id>https://sourceforge.net70588ceb17888931952eba61e232efb2a55f3644</id><summary type="html">&lt;div class="markdown_content"&gt;&lt;p&gt;This patch repeats the same code that already works for&lt;br /&gt;
the Kunststoff lnf. Is there a more elegant way to do&lt;br /&gt;
this instead of repeating the same code over and over?&lt;br /&gt;
Probably, but this works. Without the patch you will&lt;br /&gt;
end up with duplicate menu entries for the lnf since it&lt;br /&gt;
gets loaded twice -- once if it's in the pref file, and&lt;br /&gt;
once always after that.&lt;/p&gt;
&lt;p&gt;This patch was made against 1.35.&lt;/p&gt;&lt;/div&gt;</summary></entry><entry><title>Move signjar to its own target</title><link href="https://sourceforge.net/p/j-ftp/patches/6/" rel="alternate"/><published>2003-09-16T00:28:40Z</published><updated>2003-09-16T00:28:40Z</updated><author><name>Anonymous</name><uri>https://sourceforge.net/u/userid-None/</uri></author><id>https://sourceforge.net7c74a6dbcbb8ea15b19a08cfa5d42b5eca3a2d50</id><summary type="html">&lt;div class="markdown_content"&gt;&lt;p&gt;Only cdemon can build the jars without an error.&lt;/p&gt;
&lt;p&gt;This patch moves signjar to its own target so that the&lt;br /&gt;
'jars' target does not need signjar. Note that the&lt;br /&gt;
target 'dist' depends on both 'jars' and 'signjar', so&lt;br /&gt;
the jars are signed just the same as they were before.&lt;/p&gt;
&lt;p&gt;This really supercedes bug id #803429 as far as I'm&lt;br /&gt;
concerned , so you can close that if you want.&lt;/p&gt;
&lt;p&gt;This patch was applied against j-ftp 1.35.&lt;/p&gt;
&lt;p&gt;Also, you seem to have some .xvpics directories&lt;br /&gt;
included in the distribution that you'll want to&lt;br /&gt;
delete. There's also jftp-1.10.tar.gz, &lt;br /&gt;
jftp-1.11.tar.gz,  jftp-1.12.tar.gz,  and&lt;br /&gt;
jftp-1.13.tar.gz in the build directory for some&lt;br /&gt;
reason. You probably don't want to ship the source with&lt;br /&gt;
a build directory at all.&lt;/p&gt;&lt;/div&gt;</summary></entry><entry><title>Use absolute path for '.jftp' settings directory</title><link href="https://sourceforge.net/p/j-ftp/patches/5/" rel="alternate"/><published>2003-09-09T21:19:03Z</published><updated>2003-09-09T21:19:03Z</updated><author><name>David Walluck</name><uri>https://sourceforge.net/u/walluck/</uri></author><id>https://sourceforge.net51099a1c7bd338f9910c2afec7c41d4f7337be58</id><summary type="html">&lt;div class="markdown_content"&gt;&lt;p&gt;This patch makes sure that j-ftp saves to the user's&lt;br /&gt;
home directory. This prevents errors in directory&lt;br /&gt;
creation due to improper user permissions, which could&lt;br /&gt;
happen on any OS that supports user permissions,&lt;br /&gt;
including, but not limited to, Linux, Windows 2000, and&lt;br /&gt;
Windows XP.&lt;/p&gt;
&lt;p&gt;This patch was made against version 1.28. It looks like&lt;br /&gt;
an attempt was made to fix this problem in version&lt;br /&gt;
1.34. However, I am not sure it's actually fixed.&lt;br /&gt;
Please make sure that all references to the path in&lt;br /&gt;
Settings.java use 'user.home'. Otherwise, you can get&lt;br /&gt;
multiple directories under Win9x, or directory creation&lt;br /&gt;
will just outright fail in most Unix and WinNT&lt;br /&gt;
installations.&lt;/p&gt;&lt;/div&gt;</summary></entry><entry><title>Stop unsupported lnf's from being added to the j-ftp menu</title><link href="https://sourceforge.net/p/j-ftp/patches/4/" rel="alternate"/><published>2003-09-09T21:12:15Z</published><updated>2003-09-09T21:12:15Z</updated><author><name>David Walluck</name><uri>https://sourceforge.net/u/walluck/</uri></author><id>https://sourceforge.net0609e77054edb902c0685848e526cbcb6692a83c</id><summary type="html">&lt;div class="markdown_content"&gt;&lt;p&gt;This patch stops unsupported lnf's from being added to&lt;br /&gt;
the j-ftp menu, i.e., the Windows lnf on Linux and&lt;br /&gt;
vice-versa.&lt;/p&gt;
&lt;p&gt;This patch was made against version 1.28.&lt;/p&gt;&lt;/div&gt;</summary></entry><entry><title>Stop kunistoff lnf from loading multiple times</title><link href="https://sourceforge.net/p/j-ftp/patches/3/" rel="alternate"/><published>2003-09-09T21:06:17Z</published><updated>2003-09-09T21:06:17Z</updated><author><name>David Walluck</name><uri>https://sourceforge.net/u/walluck/</uri></author><id>https://sourceforge.net0cdf43c731339de3642c063799096f4842aae79b</id><summary type="html">&lt;div class="markdown_content"&gt;&lt;p&gt;This patch prevents the Kunststoff from loading as many&lt;br /&gt;
times as it wants. This patch should be extended to&lt;br /&gt;
apply to other lnf's as well.&lt;/p&gt;
&lt;p&gt;This patch was made against version 1.28.&lt;/p&gt;&lt;/div&gt;</summary></entry><entry><title>build fails if 'lib' directory doesn't exist</title><link href="https://sourceforge.net/p/j-ftp/patches/2/" rel="alternate"/><published>2003-09-09T21:03:11Z</published><updated>2003-09-09T21:03:11Z</updated><author><name>David Walluck</name><uri>https://sourceforge.net/u/walluck/</uri></author><id>https://sourceforge.netb6ee78f25e2cd4b81b958bbcf540d62ad15611b7</id><summary type="html">&lt;div class="markdown_content"&gt;&lt;p&gt;This patch isn't a very good solution to the problem,&lt;br /&gt;
but the general idea would be to not depend on jars&lt;br /&gt;
being in the lib/ directory, so that you could allow&lt;br /&gt;
them to be in the CLASSPATH instead.&lt;/p&gt;
&lt;p&gt;I guess the easiest fix would be to create the lib&lt;br /&gt;
directory in the source distribution, but this doesn't&lt;br /&gt;
eliminate the assumption that the jars in lib/ exist.&lt;/p&gt;&lt;/div&gt;</summary></entry><entry><title>Patch for sortLs Unix algorithm and rename implementation</title><link href="https://sourceforge.net/p/j-ftp/patches/1/" rel="alternate"/><published>2003-08-12T15:22:24Z</published><updated>2003-08-12T15:22:24Z</updated><author><name>Jeffrey Dahl</name><uri>https://sourceforge.net/u/jeffdahl/</uri></author><id>https://sourceforge.net756c1ed7e74fbd99cf7b98fdbf6981fc522f8d0e</id><summary type="html">&lt;div class="markdown_content"&gt;&lt;p&gt;Looks like the sortLs algorithm should be &amp;amp;quot;&amp;amp;gt; 7&amp;amp;quot; instead&lt;br /&gt;
of &amp;amp;quot;&amp;amp;gt; 8&amp;amp;quot; as there are only eight fields returned in ftp.&lt;/p&gt;
&lt;p&gt;I also needed the ability to move a file from one&lt;br /&gt;
directory to another on a remote system.  I have&lt;br /&gt;
included my implementation of ftp's rename that you may&lt;br /&gt;
look at including in your next release.&lt;/p&gt;
&lt;p&gt;Thanks,&lt;br /&gt;
Jeff Dahl&lt;/p&gt;&lt;/div&gt;</summary></entry></feed>