HTTP has a last-changed header. I think you can get similar information from FTP's ls command. I need to get this information, in a unified (protocol-independant) way, for full implementation of bug 124029 (to see, if the local or remote file is newer, to avoid conflicts and dataloss, like the 4.x "conflict" dialog for roaming). dougt suggested (on .netlib, IIRC) to use the nsIFile API for that.

Calvin Liu, this is what I talked with you about. I opened a thread about this in .netlib at 2002-09-08, Subject "Getting modification time of HTTP and FTP files": <nntp://news.mozilla.org/3D7B3397.3090301@beonex.com>.

What about sytuation when the date on PC or server will change (reset or smth.)? In this sutuation we could overwrite the newer profile with an older on a server. Maybe we should check some time server for current time and write this info say in file's name? Just thoughts?

Eugene -- that's a huge can of worms that should stay closed. :)

Agreed. Fix the server/desktop. But it's a nice idea, if this bug turns out to be too hard or impossible, esp. for a variety of protocols we may want to support. I could just write the current date for all uploaded files into another file and upload that file as well. When I retrieve, I fetch that file first and take the times in there as the mod times for the files. No server support needed, and it's protocol independant.

BenB, Sorry I can't read the thread nntp://news.mozilla.org/3D7B3397.3090301@beonex.com. But I think if we mark the profile with file-time, we may experience timezone and some other unpredictable problems. Maybe, may not? Thinking of CVS, can we use the same strategy? Here is a simple one, just FYI. 0. use a version tag file as flag, suppose start with 0 (or dot-separated format, etc.) 1. server side, the tag file can only be updated when sync 2. client side, the tag file can be updated when update locally and sync 3. whenever client version is larger than that of server, we need to update the file on server, the version should add 1, and then the client version is set equal to server version. That means the server side version are always the largest one. 4. whenever a client connects to server, it must check the version number and make a choice if need to sync 5. a new installed/configured/never synced client should have version 0 and sync down from server when it connects. client server -------------------------- 0 N/A 1 --sync--> 1 2 local update 1 3 --sync--> 2 2 2 (keep the same) 2 3 (updated by other instance) 3 <--sync-- 3 A problem is if we keep transfering whole files as a "profile set", we can't update specified key-value pair. There is a bug concerning about this issue.

The comment upstairs is not a complete approach, just FYI. For example, if there is clients wich version is 5 (locally update several times), there should be a confirm dialog that let user to choose which direction the sync should happen.

> BenB, Sorry I can't read the thread Try <http://groups.google.com/groups?selm=3D7B3397.3090301%40beonex.com> > But I think if we mark the profile with file-time, we may experience timezone > and some other unpredictable problems. Maybe, may not? Yes, we should include the timezone into the time, that should solve it, assuming client and server are conofigured correctly. > use a version tag file as flag, This might be a solution for roaming, like my idea in comment 4, but this bug was intended to be general in nature, not limited to file sync. It is a generic interface to get the last modification time of a (HTTP, FTP etc.) resource on a generic server. E.g. asking when <http://www.cnn.com> was modified the last time. We should take a look at the "View|Page Info|Last Modification" implementation, although that is probably specific to HTTP and implemented in JS.

> assuming client and server are conofigured correctly. I guess that's a bad assumption :-(. I went the listing file route with roaming, mainly because getting the stats of lots of files on the server causes significant and time-costy network roundtrips. I'll probably use a local listing file as well (the using the server's modification times from the server's listing file) to avoid a problem with the server's and client's realtime clock differing. So, removing this bug as dependency for roaming. I still think that it could be useful in general, though.

> I'll probably use a local listing file as well (the using the server's > modification times from the server's listing file) s/server's/client's/

Following comment 8, moving this off my plate.