312533 - ftp support is gone in sunbird-1.2

Status: RESOLVED WORKSFORME

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

Description

[Mark Harrison]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

In sunbird 0.2 i could give an ftp url for a remote
calendar.  it seems this functionality is removed.

how do i have sunbird publish to an ftp site?

Reproducible: Always

Comment 1

[Robin Edrenius]

I can do this, on windows, by putting an url in this format while publishing:
ftp://USERNAME:PASSWORD@URL-TO-FTP

Comment 2

[Laurentiu Nicolae]

Yes, but if the name of the ftp user contains "." this is converted to %E, if I remember correctly (which leads to auth. error). 

The fact still remains that the FTP feature should be documented.

Comment 3

[u61350]

I'm having the same problem. When i try to create a remote calendar using ftp location, i always get authentication error.

Mozilla Calendar 2006012105-cal
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060130 SeaMonkey/1.0

Comment 4

[Matthew (lilmatt) Willis]

Reassigning all automatically assigned bugs from Mostafa to nobody@m.o

Bugspam filter: TorontoMostafaMove

Comment 5

[Omar Bajraszewski]

(In reply to comment #1)
WFM with Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9a1) Gecko/20061006 Sunbird/0.3
> I can do this, on windows, by putting an url in this format while publishing:
> ftp://USERNAME:PASSWORD@URL-TO-FTP
That is wrong: it should look like: ftp://USERNAME:PASSWORD@URL-TO-FTP/calendar.ics

This bug should be closed

Comment 6

[Sebastian Schwieger]

I tried usernames that contain "." in it and found it to work for publishing. Creating a calendar using
ftp://test.benutzer:passwd@server/test.ics
gives me an error message:
550: Cant change directory ... No such file or directory

The same error occures after creating the first event in this calendar.
However, after that everything works fine.

tested with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061206 Calendar/0.4a1

Comment 7

[Philipp Kewisch [:Fallen][📱📆]]

I am having the same symptoms as Sebastian. Testing with a proftpd 1.31rc1 server, passwd authentication, supports TLS. Note my findings are the same for usernames containing a dot, so I believe this behaviour is dependant on the FTP server. 

Note also, that there definitly seems to be a bug about the number of authentication dialogs. I am asked at at least three times, but I expect to be asked only once per session, since I entered the correct login information each time. The file gets created after the third login dialog, I guess since the file did not exist at first, the code thinks a login error has happened.

The redundant login dialog is also observed by the reporter of bug 347128 in comment #2, which I think may be somehow related to the problems of this bug. He also gives some more info on where the login dialogs may come from. 

1. subscribe to a calendar file that dosent exist on the ftp server
   result: A login dialog is displayed, after entering correct info you get
           550 /home/kewisch/test.ics: No such file or directory
   server: no file is created
2. create an event on the new calendar
   result: A login dialog is displayed, after entering correct info you get
           550 /home/kewisch/test.ics: No such file or directory
   server: no file is created
   result: A second login dialog is shown. Entering correct info here creates
           the file with the event on the server and the event is shown in the
           view.
3. delete the event
   result: A login dialog is shown, after entering correct info, a new file is
           uploaded not containing the deleted event.
4. reload remote calendar
   result: no dialog, no events are shown (expected)
           event.

My suggestion would be to file a new bug about the redundant login dialogs. This bug is somewhat messy, since the initial bug talks about ftp support being gone and then a couple of other comments morphed it into a bug describing logins failing that contain a dot.

After a discussion with Sebastian, the reason we have multiple dialogs is that multiple channels are used. A spinoff bug should be filed on this. I am closing this bug as WFM.