Closed
Bug 373430
Opened 18 years ago
Closed 4 years ago
PUT without GET in FTP client-server interaction
Categories
(Calendar :: Provider: ICS/WebDAV, defect)
Calendar
Provider: ICS/WebDAV
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?
Reporter | ||
Comment 1•18 years ago
|
||
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.
Reporter | ||
Comment 2•18 years ago
|
||
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?
Reporter | ||
Comment 3•18 years ago
|
||
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).
Reporter | ||
Updated•17 years ago
|
Flags: wanted-calendar0.8?
Comment 5•17 years ago
|
||
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-
Updated•17 years ago
|
Keywords: qawanted
OS: Windows XP → All
Hardware: PC → All
Summary: put without get in ftp → PUT without GET in FTP client-server interaction
Comment 6•4 years ago
|
||
Resolving WONTFIX as FTP capability has been discontinued (bug 1574475).
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•