DO NOT REPLY [Bug 34941] - FTP uptodate calculations wrong

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34941


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2005-05-22 00:15 ---
I previously stated that I think that your problem results from a new bug.  I no
longer think so.  It's not a bug.

First of all the preserveLastModified is documented as only apply to gets, not
puts, as I previously stated, but that is irrelevant.

More importantly, you must consider timestamp resolution differences between
your local machine and the ftp server.  Even if they are on the same box,
commons-net-ftp, since it must work through directory listing formats, is
restricted to what is displayed by an FTP listing, typically, HH:mm.  Whereas
your local file system more than likely provides second resolution.  Therefore,
even if serverTimeZoneConfig is specified, the timediffmillis attribute must
also be specified, not to account for the time zone differences but to account
for the granularity difference.  A value of 6 must be set here.

I'm not sure I'm happy with this situation, but with the fix I've checked in the
task is now performing as currently documented.  The timediffmillis attribute is
becoming more of a messy "slush fund" as it handles both time zone differences
and timestamp granularity issues.  Using time zones is much better than using
timediffmillis to handle this (since you can let java "do the math", and more
importantly, because it understands daylight savings time, which timediffmillis
does not.)  The only good use left for timediffmillis is to handle granularity
issues.  I think we should think about deprecating timediffmillis in favor of an
attribute that takes some predefined granularity constants such as
"MINUTE_GRANULARITY", etc. which the task can translate into milliseconds.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34941] - FTP uptodate calculations wrong

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34941


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Target Milestone|--- |1.6.4
Version|1.7Alpha (nightly)  |1.6.3




--- Additional Comments From [EMAIL PROTECTED]  2005-05-20 01:39 ---
Also marking version to 1.6.4 
All right, Steve.  I would say that you have a bug.  The problem is NOT

1) the same as this bug  (this bug concerns the case of equal timestamps, not
cases where an older file is copied over a newer one, which is what you have).

2) caused by an all-numeric date format on the new server, which would have been
a problem that 1.4.0 could have fixed, with the right parameters.

The only thing that's the least bit fishy in your config is that 
preservelastmodified="true"  .  You might want to try it without that since the
docs say it only works for gets.  But it shouldn't cause puts to break.  That
would still be a bug.

So I would recommend logging this as a new bug.

I've also marked it as target milestone 1.6.4 since I put it in their at Antoine
's urging.



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34941] - FTP uptodate calculations wrong

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34941





--- Additional Comments From [EMAIL PROTECTED]  2005-05-19 10:55 ---
Server is Suse 9.2pro with vsftpd; It's at home (and turned off) so I cant get a
listing now. The target is 

  
  


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34941] - FTP uptodate calculations wrong

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34941


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
Version|unspecified |1.7Alpha (nightly)




--- Additional Comments From [EMAIL PROTECTED]  2005-05-19 10:02 ---
Change outlined above was made on HEAD.  Files with equal timestamps are now
considered up to date.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34941] - FTP uptodate calculations wrong

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34941





--- Additional Comments From [EMAIL PROTECTED]  2005-05-19 03:04 ---
Wait a minute, Steve.  Now I REALLY want to see your  call parameters.  Are
you using the new defaultDateFormatConfig attribute?  Does an FTP listing from
these directories look exactly like these ls listings?  

Because, if it does, we are looking at one of these newfangled UNIX ftp servers
with all-numeric date formats.  This is something new, something that
commons-net 1.4.0 addresses but 1.2.2 does not.  1.2.2 (and the default
configuration in 1.4.0) assumed that all unix ftp servers listings looked like 
this:

-rw-r--r--  1 slo users 41 May 18 23:45 diary-core-0.1alpha-src.tar.gz.sha1

You must use the defaultDateFormatConfig="-MM-dd HH:mm" attribute to handle
the numeric format you are showing if that's the way your FTP server does it. 
Actually, this makes a lot of sense.  If your server FTP listings look like that
the default parser will fail to parse them, so your destination will show NO
files existing and hence everything will get copied.  

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34941] - FTP uptodate calculations wrong

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34941





--- Additional Comments From [EMAIL PROTECTED]  2005-05-19 02:51 ---
It would seem you problem would not be fixed by the change I want to make.  That
change is simply to change this:

   if (this.action == SEND_FILES) {
   return remoteTimestamp + timeDiffMillis > localTimestamp;
   } else {
   return localTimestamp > remoteTimestamp + timeDiffMillis;
   }

to this:

   if (this.action == SEND_FILES) {
   return remoteTimestamp + timeDiffMillis >= localTimestamp;
   } else {
   return localTimestamp >= remoteTimestamp + timeDiffMillis;
   }

It would fix the problem of equal timestamps updating, but not the problem I see
here which is where the source is older than the destination but still updates.

However, to truly understand what is going on, can you supply the actual ant
target where this is happening with all the  attributes you are using?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34941] - FTP uptodate calculations wrong

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34941





--- Additional Comments From [EMAIL PROTECTED]  2005-05-19 01:13 ---
Is this also the cause of a problem I'm seeing, namely that ftp put of a set of
files to a unix localhost is always updating, even when they havent changed?
Everything works properly when uploading to a local DOS box?

source: 
core/dist> ls -al *.sha1
-rw-r--r--  1 slo users 41 2005-05-18 23:45 diary-core-0.1alpha-src.tar.gz.sha1
-rw-r--r--  1 slo users 41 2005-05-18 23:45 diary-core-0.1alpha-src.zip.sha1
-rw-r--r--  1 slo users 41 2005-05-18 23:45 diary-core-0.1alpha.tar.gz.sha1
-rw-r--r--  1 slo users 41 2005-05-18 23:45 diary-core-0.1alpha.zip.sha1

dest:
temp/upload> ls -al *.sha1
-rw-r--r--  1 slo users 41 2005-05-19 00:07 diary-core-0.1alpha-src.tar.gz.sha1
-rw-r--r--  1 slo users 41 2005-05-19 00:07 diary-core-0.1alpha-src.zip.sha1
-rw-r--r--  1 slo users 41 2005-05-19 00:07 diary-core-0.1alpha.tar.gz.sha1
-rw-r--r--  1 slo users 41 2005-05-19 00:07 diary-core-0.1alpha.zip.sha1

  [ftp] Opening FTP connection to k2
  [ftp] connected
  [ftp] logging in to FTP server
  [ftp] login succeeded
  [ftp] changing the remote directory
  [ftp] sending files
  [ftp] checking date for diary-core-0.1alpha-src.tar.gz
  [ftp] transferring
/home/slo/Projects/AntBook/app2/diary/core/dist/diary-core-0.1alpha-src.tar.gz
  [ftp] File
/home/slo/Projects/AntBook/app2/diary/core/dist/diary-core-0.1alpha-src.tar.gz
copied to k2
  [ftp] checking date for diary-core-0.1alpha-src.tar.gz.sha1
  [ftp] transferring
/home/slo/Projects/AntBook/app2/diary/core/dist/diary-core-0.1alpha-src.tar.gz.sha1
  [ftp] File
/home/slo/Projects/AntBook/app2/diary/core/dist/diary-core-0.1alpha-src.tar.gz.sha1
copied to k2
  [ftp] checking date for diary-core-0.1alpha-src.zip
  [ftp] transferring
/home/slo/Projects/AntBook/app2/diary/core/dist/diary-core-0.1alpha-src.zip
  [ftp] File
/home/slo/Projects/AntBook/app2/diary/core/dist/diary-core-0.1alpha-src.zip
copied to k2
  [ftp] checking date for diary-core-0.1alpha-src.zip.sha1
  [ftp] transferring
/home/slo/Projects/AntBook/app2/diary/core/dist/diary-core-0.1alpha-src.zip.sha1
  [ftp] File
/home/slo/Projects/AntBook/app2/diary/core/dist/diary-core-0.1alpha-src.zip.sha1
copied to k2
  [ftp] checking date for diary-core-0.1alpha.tar.gz
  [ftp] transferring
/home/slo/Projects/AntBook/app2/diary/core/dist/diary-core-0.1alpha.tar.gz
  [ftp] File
/home/slo/Projects/AntBook/app2/diary/core/dist/diary-core-0.1alpha.tar.gz
copied to k2
  [ftp] checking date for diary-core-0.1alpha.tar.gz.sha1
  [ftp] transferring
/home/slo/Projects/AntBook/app2/diary/core/dist/diary-core-0.1alpha.tar.gz.sha1
  [ftp] File
/home/slo/Projects/AntBook/app2/diary/core/dist/diary-core-0.1alpha.tar.gz.sha1
copied to k2
  [ftp] checking date for diary-core-0.1alpha.zip
  [ftp] transferring
/home/slo/Projects/AntBook/app2/diary/core/dist/diary-core-0.1alpha.zip
  [ftp] File
/home/slo/Projects/AntBook/app2/diary/core/dist/diary-core-0.1alpha.zip copied 
to k2
  [ftp] checking date for diary-core-0.1alpha.zip.sha1
  [ftp] transferring
/home/slo/Projects/AntBook/app2/diary/core/dist/diary-core-0.1alpha.zip.sha1
  [ftp] File
/home/slo/Projects/AntBook/app2/diary/core/dist/diary-core-0.1alpha.zip.sha1
copied to k2
  [ftp] 8 files sent
  [ftp] disconnecting





-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]