Closed Bug 373430 Opened 17 years ago Closed 3 years ago

PUT without GET in FTP client-server interaction

Categories

(Calendar :: Provider: ICS/WebDAV, defect)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: bvdbos, Unassigned)

Details

followup on bug 287612 comment 7 for ftp...

We should have a way to determine wether the remote ics on ftp has changed. Some servers support MDTM (file date), not all of them afaik. Lighnting does issue a SIZE and MDTM command before reloading a calendar. Maybe we can do a check on these, if the date has changed issue a reload. Though MDTM and SIZE are not yet decribed in rfc959, they are mentioned in rfc2389 (FEAT and OPTS). From what I understand googling, most ftp-servers support these commands already. For now we don't need them though. 

Before putting an ics-file on the ftp-server lightning does a reload (which is good for now). If however you don't issue the reload in lightning by hand (with refresh of the screen), the reloaded file is discarded. So my guess is fixing this for SB/Lightning with ftp can be rather easy (I'm not a developer so just a guess). 

This can be reprocuced as followed:

1) Have a ftp-calendar with two events. Open one of the events for editing. From another client (I used a ftp-client) edit the ICS by hand. Save the altered event in Lightning, notice that the handedited event is reverted back although the ftp-logs indicate a GET was issued before the PUT.

2) Have a ftp-calendar with two events. Open one of the events for editing. From another client (I used a ftp-client) edit the ICS by hand and then issue a reload in Lightning (still having the modeless event open for editing). notice the hand-edited event has changed in lightning. Save the edited event in Lightning, notice that both events have changed.
Flags: blocking-calendar0.5?
ftp-transaction when putting event:

>FTP command: Client "192.168.2.11", "PASV"
>FTP response: Client "192.168.2.11", "227 Entering Passive Mode (192,168,2,10,217,9)"
>FTP command: Client "192.168.2.11", "SIZE /home/bas/Bas.ics"
>FTP response: Client "192.168.2.11", "213 8342"
>FTP command: Client "192.168.2.11", "MDTM /home/bas/Bas.ics"
>FTP response: Client "192.168.2.11", "213 20070310083310"
>FTP command: Client "192.168.2.11", "RETR /home/bas/Bas.ics"
>FTP response: Client "192.168.2.11", "150 Opening BINARY mode data connection for /home/bas/Bas.ics (8342 bytes)."
>FTP response: Client "192.168.2.11", "226 File send OK."
>OK DOWNLOAD: Client "192.168.2.11", "/home/bas/Bas.ics", 8342 bytes, 696.40Kbyte/sec
>FTP command: Client "192.168.2.11", "PASV"
>FTP response: Client "192.168.2.11", "227 Entering Passive Mode (192,168,2,10,117,210)"
>FTP command: Client "192.168.2.11", "CWD /home/bas/"
>FTP response: Client "192.168.2.11", "250 Directory successfully changed."
>FTP command: Client "192.168.2.11", "STOR Bas.ics"
>FTP response: Client "192.168.2.11", "150 Ok to send data."
>FTP response: Client "192.168.2.11", "226 File receive OK."
>OK UPLOAD: Client "192.168.2.11", "/home/bas/Bas.ics", 8645 bytes, 839.04Kbyte/sec

both with TB1.5.0.10 and TB2.0b2 with lightning .5pre (2007030205) on windows with vsftd as ftp-server.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3pre) Gecko/20070303 Calendar/0.5pre

the behaviour is different. After the manual reload in step 2 the event is changed, the errorconsole reports:
Error: Severe error in internal transaction code!
old item mismatch in modifyItem
Please report this to the developers.

Source File: chrome://calendar/content/calendar-item-editing.js
Line: 351

Getting back at my previous comment: TB reports the same error. I'm not able to reproduce the previous behaviour now?
apart from reloading the calendar before putting an event, we want to check if the event what was openend for editing didn't change in the meanwhile, other events on the calendar should be allowed to change (and are catched by the reload). This means the event LAST-MODIFIED shouldn't have changed. 

The best behaviour for ftp when editing an event would be (imho):
1) Check for filedate - if this wasn't changed just put the new file (preventing unnessecary datatransfer)
2) If the filedate has changed (or the ftp-server doesn't support MDTM) reload the calendar and check for LAST-MODIFIED property of the event. If this hasn't changed, just put the event. If this has changed issue a warning before putting the event (overwrite changes yes/no). 
This won't block 0.5.
Flags: blocking-calendar0.5? → blocking-calendar0.5-
Keywords: qawanted
Flags: wanted-calendar0.8?
Setting wanted0.8- as the main Calendar developers will not devote any time to
this in the 0.8 timeframe. Patches are, of course, always welcome.
Flags: wanted-calendar0.8?
Flags: wanted-calendar0.8-
Flags: blocking-calendar0.5-
Keywords: qawanted
OS: Windows XP → All
Hardware: PC → All
Summary: put without get in ftp → PUT without GET in FTP client-server interaction

Resolving WONTFIX as FTP capability has been discontinued (bug 1574475).

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.