User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6 I use the function reload remote calendear at startup. Sometimes I get an error that a ermote calendar file could not be loaded (but the calendar is not disabled and shown as normal), because my ftp-server accepts only one connection at a time. After modifying this calendar the new data are written without trying to reload the remote calendar before. Thus all old are lost and overwritten by the last modification. Reproducible: Always Steps to Reproduce: se description above Actual Results: data loss Expected Results: - Disabling no correctly loaded remote calendars - Reloading remote calendars before writing modifications - at least a warning, that data may be lost !!!!

Bug 287612 handles the reloading part.

BTW, confirming the lacking of the errormessage and setting to read-only.

Wow... I was to post a new bug about that when I found this... My config : Thunderbird 2.0.0.5 + Lightning 0.7 (Linux) My server : ftpperso.free.fr (max 2 simultaneous connections) 3 remote calendars declared Symptom : A dialog box "421 Too many connections - max 2 allowed" pops up at startup and every time I try to reload remote calendard. Then the events from the two "first" calendars are displayed, but not those from the 3rd one. Then if I create an event in the 3rd calendar, a new ICS file is uploaded to the FTP server, erasing the previous one and all its events. Suggested fix : have the "remote calendar engine" reuse connections to a given server, processing retrieving sequentially (one request at a time for a given server). Or (better) : add a config parameter "max concurrent connections while retrieveing remote calendard". Or (even better) : detect "too many connections" errors, wait a little, then retry.

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.