On Fri, Mar 6, 2009 at 8:30 PM, David Latorre wrote:
> Do you know when it's likely that getCanonical* fails? Should we try a
> workaround in that case? If you think our code is ok as is, that's much
> better!
I have no idea, which is why I choose to throw the exception. I'm also
okay with swal
2009/3/6 Emmanuel Lecharny
> Niklas Gustavsson wrote:
>
>> On Fri, Mar 6, 2009 at 11:57 AM, Emmanuel Lecharny
>> wrote:
>>
>>
>>> Just a small remark : it would be _very_ cool if you can extend the
>>> NativeFtpFile interface with a getFile() method, because having to cast
>>> the
>>> object to
Niklas Gustavsson wrote:
On Fri, Mar 6, 2009 at 11:57 AM, Emmanuel Lecharny wrote:
Just a small remark : it would be _very_ cool if you can extend the
NativeFtpFile interface with a getFile() method, because having to cast the
object to get the so called PhysicalFile is a bit a PITA, IMHO :)
On Fri, Mar 6, 2009 at 12:04 PM, Emmanuel Lecharny wrote:
> Apple, I know at least 8 persons who need a Mac Book Pro 17", 8 Gb, Quad
> core 3Ghz, 300 Gb SSD disk, 6h battery...
Yeah, send one my way :-D
/niklas
On Fri, Mar 6, 2009 at 11:57 AM, Emmanuel Lecharny wrote:
> Just a small remark : it would be _very_ cool if you can extend the
> NativeFtpFile interface with a getFile() method, because having to cast the
> object to get the so called PhysicalFile is a bit a PITA, IMHO :)
Not sure I understand,
David Latorre wrote:
After changing NativeFtpFile equals to the followingcode :
@Override
public boolean equals(Object obj) {
try{
if(obj != null && obj instanceof NativeFtpFile) {
return this.file.getCanonicalPath().equals( ((NativeFtpFile)
obj).file.getCanonicalPath() ) ;
Niklas Gustavsson wrote:
I've moved the patch into NativeFtpFile where it belongs, and the test
still pass on Linux. I've commited this to trunk (rev 750819),
Emmanuel would you be able to rerun the test from trunk? If it passed,
I will merge this into the 1.0.x branch as well.
Will do.
Just
2009/3/6 Emmanuel Lecharny
> Sai Pullabhotla wrote:
>
>> That's what I was expecting. So, if the issue is about RMDIR on the
>> current
>> working directory, we should be able to match up the canonical paths and
>> if
>> they are same (the directory that was requested for deletion and the
>> curr
On Fri, Mar 6, 2009 at 12:56 AM, Emmanuel Lecharny wrote:
> Ok, I have changed the RMDIR impl, and now, all the tests are passing.
This is great news!
> Could someone do the test on W$ and Linux ?
I've moved the patch into NativeFtpFile where it belongs, and the test
still pass on Linux. I've c
Sai Pullabhotla wrote:
That's what I was expecting. So, if the issue is about RMDIR on the current
working directory, we should be able to match up the canonical paths and if
they are same (the directory that was requested for deletion and the current
working directory), send an error back. Does
That's what I was expecting. So, if the issue is about RMDIR on the current
working directory, we should be able to match up the canonical paths and if
they are same (the directory that was requested for deletion and the current
working directory), send an error back. Does that sound correct?
Sai
Niklas Gustavsson wrote:
On Thu, Mar 5, 2009 at 8:55 PM, Emmanuel Lecharny wrote:
i'm pretty sure I tested it, and the getCanonicalPath() keeps the name which
as been used on HSF+.
Could you please clarify that? If a file exists with the name "foo",
and we call new File("FOO").getCano
On Thu, Mar 5, 2009 at 8:55 PM, Emmanuel Lecharny wrote:
> i'm pretty sure I tested it, and the getCanonicalPath() keeps the name which
> as been used on HSF+.
Could you please clarify that? If a file exists with the name "foo",
and we call new File("FOO").getCanonicalPath(), what casing will it
Niklas Gustavsson wrote:
On Thu, Mar 5, 2009 at 5:34 PM, Sai Pullabhotla
wrote:
I would like to take this one step back as I think that the
getCanonicalFile() or getCanonicalPath() on an existing file should return
the exact file name with the correct case as it is stored on the file
system.
On Thu, Mar 5, 2009 at 5:34 PM, Sai Pullabhotla
wrote:
> I would like to take this one step back as I think that the
> getCanonicalFile() or getCanonicalPath() on an existing file should return
> the exact file name with the correct case as it is stored on the file
> system. At least that is what
I would like to take this one step back as I think that the
getCanonicalFile() or getCanonicalPath() on an existing file should return
the exact file name with the correct case as it is stored on the file
system. At least that is what the JavaDoc says.
Can some one run this test program on OS X/HF
Works fine on Fedora 10, ext2, ext3 and ntfs mounted with ntfs-3g (fuseblk)
For the mounted ntfs partition I had to use CaseSensitive.
Maarten
On Thu, Mar 5, 2009 at 10:39 AM, Emmanuel Lecharny wrote:
> Works fine on my Mac OS X 10.4/Java 5
>
> On Wed, Mar 4, 2009 at 11:13 PM, Niklas Gustavsson
Works fine on my Mac OS X 10.4/Java 5
On Wed, Mar 4, 2009 at 11:13 PM, Niklas Gustavsson wrote:
> On Mon, Mar 2, 2009 at 4:54 PM, Niklas Gustavsson
> wrote:
>> Let me whip up a prototype and we can test it on the available platforms.
>
> Alright, here's a prototype that I would much appreciate
On Mon, Mar 2, 2009 at 4:54 PM, Niklas Gustavsson wrote:
> Let me whip up a prototype and we can test it on the available platforms.
Alright, here's a prototype that I would much appreciate if all of you
would take the time to test. First of all, you need to set the
FILE_SYSTEM_TYPE to the correc
On Mon, Mar 2, 2009 at 8:02 PM, Maarten Bosteels
wrote:
> Would it be a viable option to let users of FtpServer define which
> mount-points use a case-insensitive file-system ?
> I mean an out-of-the-box FtpServer config that works for 95% of the
> user-base and the other 5% would have to do some
Would it be a viable option to let users of FtpServer define which
mount-points use a case-insensitive file-system ?
I mean an out-of-the-box FtpServer config that works for 95% of the
user-base and the other 5% would have to do some extra configuration.
Maarten
On Mon, Mar 2, 2009 at 6:12 PM, N
On Mon, Mar 2, 2009 at 6:01 PM, Sai Pullabhotla
wrote:
> Does this help at all?
>
> http://lists.apple.com/archives/java-dev/2004/Feb/msg00331.html
I've posted this previously in this thread, however they do not seem
to reach any conclusion beyond this being more complex that you might
think :-)
Does this help at all?
http://lists.apple.com/archives/java-dev/2004/Feb/msg00331.html
Sai Pullabhotla
Phone: (402) 408-5753
Fax: (402) 408-6861
www.jMethods.com
On Mon, Mar 2, 2009 at 9:54 AM, Niklas Gustavsson wrote:
> On Mon, Mar 2, 2009 at 1:17 PM, Emmanuel Lecharny
> wrote:
> > It may b
On Mon, Mar 2, 2009 at 1:17 PM, Emmanuel Lecharny wrote:
> It may be just a matter of checking that the file can be deleted, then check
> that the working directory still exists after having done the deletion. If
> so, we are golden, otherwise, we have to recreate it, and send an error.
Recreatin
What about taking the problem from the other side ?
The test fails because :
- we are trying to delete the current working directory
- doing a
FtpFile cwd = session.getFileSystemView().getWorkingDirectory();
if(file.equals(cwd)) {
does not work on Mac OS X and Java 6 because the file handl
On Mon, Mar 2, 2009 at 4:34 PM, Niklas Gustavsson wrote:
> On Mon, Mar 2, 2009 at 11:52 AM, Ashish wrote:
>> Can't we create the name like File file = new
>> File("FiLe"+System.currentTimeMillis());
>> check if it exists. Chance are very rare that it will.
>>
>> If it exist recreate a new file na
On Mon, Mar 2, 2009 at 11:52 AM, Ashish wrote:
> Can't we create the name like File file = new
> File("FiLe"+System.currentTimeMillis());
> check if it exists. Chance are very rare that it will.
>
> If it exist recreate a new file name.
> If it doesn't exist, we call file.createNewFile(); and do t
On Mon, Mar 2, 2009 at 4:00 PM, Niklas Gustavsson wrote:
> On Mon, Mar 2, 2009 at 11:01 AM, Emmanuel Lecharny
> wrote:
>> Nah, i'm wrong. I'm confusing the two issues : the socket error and the case
>> sensitive directory error.
>
> Damn. Okay, think out loud, could we do an equals implementatio
On Mon, Mar 2, 2009 at 11:01 AM, Emmanuel Lecharny wrote:
> Nah, i'm wrong. I'm confusing the two issues : the socket error and the case
> sensitive directory error.
Damn. Okay, think out loud, could we do an equals implementation that:
1. Check if equals return true, if so, return true
2. Else,
On Mon, Mar 2, 2009 at 11:19 AM, Maarten Bosteels
wrote:
> But even when it's not fixed in java 6...
> When it's a JVM bug on OS X, and there is no clean work-around, then IMO we
> shouldn't jumpt through too many hoops trying to solve it.
I'm not sure we can really claim this to be a bug in the
But even when it's not fixed in java 6...
When it's a JVM bug on OS X, and there is no clean work-around, then IMO we
shouldn't jumpt through too many hoops trying to solve it.
Maarten
On Mon, Mar 2, 2009 at 11:01 AM, Emmanuel Lecharny wrote:
> Niklas Gustavsson wrote:
>
>> On Sun, Mar 1, 2009 a
Niklas Gustavsson wrote:
On Sun, Mar 1, 2009 at 11:06 PM, Emmanuel Lecharny wrote:
I'm not
really happy with this but I can't figure out a better way, besides
someone fixing the JVM.
Btw, it's fixed in Java 6 on Mac OSX, AFAICT. The biggest issue is that you
can't run this JVM on OS
On Sun, Mar 1, 2009 at 11:06 PM, Emmanuel Lecharny wrote:
>> I'm not
>> really happy with this but I can't figure out a better way, besides
>> someone fixing the JVM.
>
> Btw, it's fixed in Java 6 on Mac OSX, AFAICT. The biggest issue is that you
> can't run this JVM on OS X 10.4.
Really? If so,
Niklas Gustavsson wrote:
On Fri, Feb 27, 2009 at 1:36 PM, Emmanuel Lecharny wrote:
Given a file name which might not be in the correct casing, is there a
way to detect the "real" casing in HSF+? For example, what would the
following return?
new File("FOO").getName()
new File("FOO").getAbsolu
On Fri, Feb 27, 2009 at 2:06 PM, Ashish wrote:
> Is OS name not sufficient for this? Agree that it leads to hard-coding.
HFS+ seems to be able to have different settings that affect the case
handling, thus looking at the OS name will not help. Also, you can
mount an ext3 file system on a Mac or a
On Fri, Feb 27, 2009 at 1:36 PM, Emmanuel Lecharny wrote:
>> Given a file name which might not be in the correct casing, is there a
>> way to detect the "real" casing in HSF+? For example, what would the
>> following return?
>> new File("FOO").getName()
>> new File("FOO").getAbsolutePath()
>> new
>
> File f1 = new File( "test" );
> File f2 = new File( "TEST" );
>
> if ( !f1.equals( f2 ) ) {
> if ( f1.createNewFile() != f2.createNewFile() ) {
> // Case insensitive but name preserving
> } else {
> // case sensitive
> }
> } else {
> // case insensitive
> }
>
> Maybe someone else
Niklas Gustavsson wrote:
On Fri, Feb 27, 2009 at 12:04 PM, Emmanuel Lecharny
wrote:
Files are considered as different.
This makes our task somewhat harder :-) So, on OS X, if we got a
directory (or file I assume) called "foo", the following will be
correct, right?
new File("foo").equ
On Fri, Feb 27, 2009 at 12:04 PM, Emmanuel Lecharny
wrote:
> Files are considered as different.
This makes our task somewhat harder :-) So, on OS X, if we got a
directory (or file I assume) called "foo", the following will be
correct, right?
new File("foo").equals(new File("FOO")) => false
new F
Niklas Gustavsson wrote:
On Fri, Feb 27, 2009 at 11:36 AM, Emmanuel Lecharny
wrote:
Ok, we have run the tests again and the problem is that using HSF+ file
system on Mac, the RMD command in the testRmdirCurrentWorkingDirectory test
simply succeed, because HSF+ can be set to be case-insensiti
On Fri, Feb 27, 2009 at 11:36 AM, Emmanuel Lecharny
wrote:
> Ok, we have run the tests again and the problem is that using HSF+ file
> system on Mac, the RMD command in the testRmdirCurrentWorkingDirectory test
> simply succeed, because HSF+ can be set to be case-insensitive.
That's bad, because
Julien Vermillard wrote:
Would you be able to send me the debug level log for this failing
test?
Will do asap.
Ok, we have run the tests again and the problem is that using HSF+ file
system on Mac, the RMD command in the testRmdirCurrentWorkingDirectory
test simply succeed, beca
Le Fri, 27 Feb 2009 09:37:24 +0100,
Emmanuel Lecharny a écrit :
> Niklas Gustavsson wrote:
> > On Fri, Feb 27, 2009 at 1:17 AM, Emmanuel Lecharny
> > wrote:
> >> We haved conducted more tests this afternoon, using another JVM on
> >> Mac OS X 10.5 (java 6), and didn't had the same problem.
> >>
Niklas Gustavsson wrote:
On Fri, Feb 27, 2009 at 1:17 AM, Emmanuel Lecharny wrote:
We haved conducted more tests this afternoon, using another JVM on Mac OS X
10.5 (java 6), and didn't had the same problem.
Sounds like we can conclude that it's a JVM bug then.
This is also my opi
On Fri, Feb 27, 2009 at 1:17 AM, Emmanuel Lecharny wrote:
> We haved conducted more tests this afternoon, using another JVM on Mac OS X
> 10.5 (java 6), and didn't had the same problem.
Sounds like we can conclude that it's a JVM bug then.
> Here is the failing test in
> this case :
Would you b
We haved conducted more tests this afternoon, using another JVM on Mac
OS X 10.5 (java 6), and didn't had the same problem. Here is the failing
test in this case :
---
Test set: org.apache.ftpserver.clienttests.RmDirTes
On Sat, Feb 21, 2009 at 9:29 PM, Niklas Gustavsson wrote:
> [X]: +1, Release FtpServer 1.0.0
/niklas
Guillaume Nodet wrote:
On OS X, the test does not behave the same way: the session is created
and the byte written, but the server does not have any managed session
so the last assertion fails.
Can someone test the code with Mac OS x 1.0.5/Java 6 ?
--
--
cordialement, regards,
Emmanuel Léch
On Wed, Feb 25, 2009 at 10:00 AM, Guillaume Nodet wrote:
> Imho, we should just document that as a defect and not wait for a new
> release of Mina to fix that.
> I don't even think this would require any code change in ftpserver as
> the problem seems really related to mina.
> Adding a line in the
Guillaume Nodet wrote:
On Mon, Feb 23, 2009 at 01:58, Guillaume Nodet wrote:
I've just downloaded the sources tar.gz and tried to build those.
The org.apache.ftpserver.clienttests.SuspendResumeTest is hanging
forever. Is that a know thing ?
Imho, we should just document that as a def
On Mon, Feb 23, 2009 at 01:58, Guillaume Nodet wrote:
> I've just downloaded the sources tar.gz and tried to build those.
> The org.apache.ftpserver.clienttests.SuspendResumeTest is hanging
> forever. Is that a know thing ?
Imho, we should just document that as a defect and not wait for a new
re
Guillaume Nodet wrote:
On OS X, the test does not behave the same way: the session is created
and the byte written, but the server does not have any managed session
so the last assertion fails.
To make this test fail as expected, I need to add the following calls
to AbstractPollingIoAcceptor#unbi
On OS X, the test does not behave the same way: the session is created
and the byte written, but the server does not have any managed session
so the last assertion fails.
To make this test fail as expected, I need to add the following calls
to AbstractPollingIoAcceptor#unbind0
startupAccep
Guillaume Nodet wrote:
I've just spotted that the acceptor is not correctly disposed.
I've managed to get the test running succesfully by adding the
following code just after server.suspend()
for (Listener listener :
server.getServerContext().getListeners().values()) {
if (li
I've just spotted that the acceptor is not correctly disposed.
I've managed to get the test running succesfully by adding the
following code just after server.suspend()
for (Listener listener :
server.getServerContext().getListeners().values()) {
if (listener instanceof NioList
On Tue, Feb 24, 2009 at 4:36 PM, Guillaume Nodet wrote:
> Maybe not the suspend call directly, but as a side effect.
> If the server is not started, the correct expceiton if thrown by the client.
> If the server is suspended and restarted, then the client connects correctly.
yeah, probably. I sus
Maybe not the suspend call directly, but as a side effect.
If the server is not started, the correct expceiton if thrown by the client.
If the server is suspended and restarted, then the client connects correctly.
2009/2/24 Emmanuel Lecharny :
> On Tue, Feb 24, 2009 at 3:45 PM, Guillaume Nodet wr
On Tue, Feb 24, 2009 at 3:45 PM, Guillaume Nodet wrote:
> This explanation is more in line with what I found. I'm not sure
> either why the socket connection works. I've tried to add a sleep
> between the suspend and connect but to no avail.
I don't think that the suspend is the origin of the p
This explanation is more in line with what I found. I'm not sure
either why the socket connection works. I've tried to add a sleep
between the suspend and connect but to no avail.
2009/2/24 Emmanuel Lecharny :
> Ok, I have been able to go a bit further on Windows.
>
> The slector.keys().isEmpty(
Ok, I have been able to go a bit further on Windows.
The slector.keys().isEmpty() returns true too, so we also exit from
the server acceptor loop.
When the client tries to connect again, it can't and an exception is
thrown (which is expected).
As far as I remember, on mac, this is where the test
Niklas Gustavsson wrote:
Hey,
this is the vote for the big one dot oh. After our two release
candidates, we have fixed two minor bugs and I think we're now ready
to go. After 1.0.0, we will start working on patch releases on the 1.0
branch as well as new features for 1.1.
You can find the binar
On Tue, Feb 24, 2009 at 9:46 AM, Niklas Gustavsson wrote:
> On Tue, Feb 24, 2009 at 1:27 AM, Emmanuel Lecharny
> wrote:
>> What's happening is that when the session is disconnected in the test :
>
> [snip]
>>
>> In other words, the server is *dead*.
>
> So, if I understand your correctly, this
On Tue, Feb 24, 2009 at 1:27 AM, Emmanuel Lecharny wrote:
> What's happening is that when the session is disconnected in the test :
[snip]
>
> In other words, the server is *dead*.
So, if I understand your correctly, this happens on a client
disconnect? That seems very odd as it would break lot
Some more info.
I have investigated the pb on Mac & Linux. Its behavior is different.
What's happening is that when the session is disconnected in the test :
public void testSuspendResumeServer() throws Exception {
// connect should work as expected
client.connect("localhost",
Sorry for the polution ... There were two thread dump in the previous
post. Here is the important one :
Full thread dump Java HotSpot(TM) Client VM (1.5.0_16-132 mixed mode, sharing):
"Low Memory Detector" daemon prio=5 tid=0x00608e60 nid=0x1815800
runnable [0x..0x]
"CompilerTh
I confirm the pb on Mac, Java 1.5.0_16. here is a thread dump :
[] [] [] Native filesystem view created for user "null" with root
"/Users/elecharny/ftpserver-1.0/ftpserver-1.0.0/core/test-tmp/ftproot/"
[] [] [] Native filesystem view created for user "null" with root
"/Users/elecharny/ftpserver-1
On Mon, Feb 23, 2009 at 12:54 PM, Guillaume Nodet wrote:
> Is that what you are looking for:
>
> gnodet:~$ netstat -an | grep 12321
> tcp4 0 0 127.0.0.1.12321127.0.0.1.50593ESTABLISHED
> tcp4 0 0 127.0.0.1.50593127.0.0.1.12321ESTABLISHED
> tc
Is that what you are looking for:
gnodet:~$ netstat -an | grep 12321
tcp4 0 0 127.0.0.1.12321127.0.0.1.50593ESTABLISHED
tcp4 0 0 127.0.0.1.50593127.0.0.1.12321ESTABLISHED
tcp4 0 0 *.12321*.*LIST
On Mon, Feb 23, 2009 at 12:39 PM, Niklas Gustavsson
wrote:
> Commited to trunk and the 1.0.x branch. The client socket should time
> out after 10 seconds.
Note that while this might cause the test now to work (due to the
socket timing out), that's not really fixing the problem. Getting the
socket
On Mon, Feb 23, 2009 at 11:20 AM, Niklas Gustavsson
wrote:
>> The timeout on the socket is set to 0, so I suspect it will just wait
>> forever ...
>
> Well, at least longer then anyone cares to wait around. I'll set a
> shorter timeout for it.
Commited to trunk and the 1.0.x branch. The client so
2009/2/23 Niklas Gustavsson
> Moving this to it's own thread.
>
> On Mon, Feb 23, 2009 at 11:08 AM, Guillaume Nodet
> wrote:
> > FWIW, the test is hanging at the following point:
>
> Looks another case of TCP/IP stacks behaving differently on different
> platforms. Would you be able to see what
Le Sat, 21 Feb 2009 21:29:52 +0100,
Niklas Gustavsson a écrit :
> Hey,
>
> this is the vote for the big one dot oh. After our two release
> candidates, we have fixed two minor bugs and I think we're now ready
> to go. After 1.0.0, we will start working on patch releases on the 1.0
> branch as we
+1, Release FtpServer 1.0.0
2009/2/21 Niklas Gustavsson
> Hey,
>
> this is the vote for the big one dot oh. After our two release
> candidates, we have fixed two minor bugs and I think we're now ready
> to go. After 1.0.0, we will start working on patch releases on the 1.0
> branch as well as ne
Moving this to it's own thread.
On Mon, Feb 23, 2009 at 11:08 AM, Guillaume Nodet wrote:
> FWIW, the test is hanging at the following point:
Looks another case of TCP/IP stacks behaving differently on different
platforms. Would you be able to see what state the server socket is in
when this happ
FWIW, the test is hanging at the following point:
m...@1, priority=5, in group 'main', status: 'RUNNING'
at java.net.SocketInputStream.socketRead0(SocketInputStream.java:-1)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at
sun.nio.cs.StreamDecoder$Ch
On Mon, Feb 23, 2009 at 10:49 AM, Niklas Gustavsson
wrote:
> On Mon, Feb 23, 2009 at 10:27 AM, Guillaume Nodet wrote:
>> On Mon, Feb 23, 2009 at 10:21, Niklas Gustavsson
>> wrote:
>>> On Mon, Feb 23, 2009 at 1:58 AM, Guillaume Nodet wrote:
I've just downloaded the sources tar.gz and tried
On Mon, Feb 23, 2009 at 10:27 AM, Guillaume Nodet wrote:
> On Mon, Feb 23, 2009 at 10:21, Niklas Gustavsson wrote:
>> On Mon, Feb 23, 2009 at 1:58 AM, Guillaume Nodet wrote:
>>> I've just downloaded the sources tar.gz and tried to build those.
>>> The org.apache.ftpserver.clienttests.SuspendResu
On Mon, Feb 23, 2009 at 10:21, Niklas Gustavsson wrote:
> On Mon, Feb 23, 2009 at 1:58 AM, Guillaume Nodet wrote:
>> I've just downloaded the sources tar.gz and tried to build those.
>> The org.apache.ftpserver.clienttests.SuspendResumeTest is hanging
>> forever. Is that a know thing ?
>
> No, n
On Mon, Feb 23, 2009 at 1:58 AM, Guillaume Nodet wrote:
> I've just downloaded the sources tar.gz and tried to build those.
> The org.apache.ftpserver.clienttests.SuspendResumeTest is hanging
> forever. Is that a know thing ?
No, never heard about it before. We're not doing any weird things in
t
+1
On Feb 22, 2009, at 6:06 PM, Erix Yao wrote:
+1
2009/2/23 Guillaume Nodet
I've just downloaded the sources tar.gz and tried to build those.
The org.apache.ftpserver.clienttests.SuspendResumeTest is hanging
forever. Is that a know thing ?
Also, the README.txt in the binary distribution
+1
2009/2/23 Guillaume Nodet
> I've just downloaded the sources tar.gz and tried to build those.
> The org.apache.ftpserver.clienttests.SuspendResumeTest is hanging
> forever. Is that a know thing ?
>
> Also, the README.txt in the binary distribution seems quite outdated
> (talking about 1.0-M2
I've just downloaded the sources tar.gz and tried to build those.
The org.apache.ftpserver.clienttests.SuspendResumeTest is hanging
forever. Is that a know thing ?
Also, the README.txt in the binary distribution seems quite outdated
(talking about 1.0-M2 and the incubator).
On Sat, Feb 21, 2009
[X ]: +1, Release FtpServer 1.0.0
+1
On Sat, Feb 21, 2009 at 6:00 PM, Emmanuel Lecharny wrote:
>
>> [X]: +1, Release FtpServer 1.0.
>>
>
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
[X]: +1, Release FtpServer 1.0.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Hey,
this is the vote for the big one dot oh. After our two release
candidates, we have fixed two minor bugs and I think we're now ready
to go. After 1.0.0, we will start working on patch releases on the 1.0
branch as well as new features for 1.1.
You can find the binaries and Maven artifacts her
On Sat, Jan 24, 2009 at 9:23 PM, Niklas Gustavsson wrote:
> [X]: +1, Release FtpServer 1.0.0-RC2
/niklas
[X]: +1, Release FtpServer 1.0.0-RC2
2009/1/26 Maarten Bosteels
> [X]: +1, Release FtpServer 1.0.0-RC2
>
> On Mon, Jan 26, 2009 at 11:12 AM, Emmanuel Lecharny >wrote:
>
> > Oops, I meant :
> >
> > [X]: +1, Release FtpServer 1.0.0-RC2
> >
> > On Mon, Jan 26, 2009 at 11:11 AM, Emmanuel Lecharny
[X]: +1, Release FtpServer 1.0.0-RC2
On Mon, Jan 26, 2009 at 11:12 AM, Emmanuel Lecharny wrote:
> Oops, I meant :
>
> [X]: +1, Release FtpServer 1.0.0-RC2
>
> On Mon, Jan 26, 2009 at 11:11 AM, Emmanuel Lecharny
> wrote:
> >> [X ]: +1, Don't release FtpServer 1.0.0-RC2
> >
> > Instead of waiting
Oops, I meant :
[X]: +1, Release FtpServer 1.0.0-RC2
On Mon, Jan 26, 2009 at 11:11 AM, Emmanuel Lecharny wrote:
>> [X ]: +1, Don't release FtpServer 1.0.0-RC2
>
> Instead of waiting a bit, as some bugs have been fixed since RC1, I
> would rather see this version released, and wait a bit before
>
> [X ]: +1, Don't release FtpServer 1.0.0-RC2
Instead of waiting a bit, as some bugs have been fixed since RC1, I
would rather see this version released, and wait a bit before
releasing the final version. It's not really a problem to have many
RC, as soon as we move forward a GA !
--
Regards,
Co
On Mon, Jan 26, 2009 at 9:08 AM, Ashish wrote:
> [X ]: -1, Don't release FtpServer 1.0.0-RC2
>
> Would recommend to wait a while before this release. We just had a
> release. Give some time to users, to consume the new release and play
> around with it.
My hope is that we can quickly get new rele
[X ]: -1, Don't release FtpServer 1.0.0-RC2
Would recommend to wait a while before this release. We just had a
release. Give some time to users, to consume the new release and play
around with it.
On Sun, Jan 25, 2009 at 1:53 AM, Niklas Gustavsson wrote:
> Hi
>
> After the release of FtpServer
Hi
After the release of FtpServer 1.0.0-RC1 a few last minutes bugs was
discovered. These have now been fixed, and this is the vote for the
second release candidate. If all goes well, this is what will become
1.0.0. No API changes have been made in this release, only bug fixes.
You can find the b
On Fri, Jan 9, 2009 at 11:43 PM, Niklas Gustavsson wrote:
> [X]: +1, Release FtpServer 1.0.0-RC1
/niklas
Niklas Gustavsson wrote:
[X]: +1, Release FtpServer 1.0.0-RC1
> [X]: +1, Release FtpServer 1.0.0-RC1
> [ ]: 0, Abstain
> [ ]: -1, Don't release FtpServer 1.0.0-RC1
2009/1/12 Julien Vermillard
> > [X]: +1, Release FtpServer 1.0.0-RC1
> > [ ]: 0, Abstain
> > [ ]: -1, Don't release MINA 1.0.0-RC1
>
> Julien
>
> [X]: +1, Release FtpServer 1.0.0-RC1
> [ ]: 0, Abstain
> [ ]: -1, Don't release MINA 1.0.0-RC1
Julien
signature.asc
Description: PGP signature
[X]: +1, Release FtpServer 1.0.0-RC1
On Fri, Jan 9, 2009 at 11:48 PM, Emmanuel Lecharny wrote:
> Niklas, the third option refers to MINA-1.0.0 ... I fixed it here.
Oh, my crappy copy-paste fingers.
/niklas
1 - 100 of 123 matches
Mail list logo
