Best thing about Yummy is... Jason. So much stuff we ask for... we get.

Eeek, she REALLY needs to do something with that site... it looks like the only work she does is that 20+ year old stuff. I'm surprised...

Wonder what Susan Kare is dong these days???

Is the "image file" in a "standard" kind of image format? And that way in the application bundle? Should be easy to "color" I would think...

If there IS a next time, trust me I'm saving the bookmark!

Unfortunately, I can't supply them... when I discovered a brand new one worked, I tossed the old one, spazzing on the fact that I SHOULD have saved the miscreant bookmark. It's gone at this point. I pulled out my backed up one and it seemed to NOT have auto-detect. Enabling it and MDTM made it handle dates/time correctly.

On the surface, it appears I turned auto detect off, that March backup certainly did not have it set. The really odd thing is that in the past it MUST have been turned on because I know I did a number of syncs that worked exactly like they should. My going into it and turned auto-detect off is just too far fetched to think I actually did it, I can't recall much of ANY "lost" weekends like Ray Milland had...

Do I have the original bookmark? But of COURSE, I actually DO back stuff up. BUT I could almost guarentee you they'll be identical! Could be I totally lost my mind, but I DID send you an image of bunged up time/dates! Anyway, I can see how I had the toolbar set up in the old one once I get it out.

They'll be on their way later today.

Ooops, I looked at my backed up March 2007 version. Auto detect was turned off. I have NO idea how that happened, I doubt I actually disabled it. Sync DID work correctly in the past. Of course, when I was testing the whole scenario, I DID enable auto-detect and still had issues/problems. More than once.

Oh well.

I dunno, I enabled auto-detect and MDTM to the "old" bookmark, and now IT behaves correctly. Of course, while I was going crazy yesterday, I did the exact same things, but did NOT get the results I got today.

Sorry, I had done the things I detailed in my last post before I read those suggestions!

Indeed, it was the "automatically" that "reset" it to "ahead" from my manually setting it "behind." I suspect I missed it because I saw editable  fields and a check box and used them (I probably thought "one needs the checkbox to enable the manual settings"). But this is a side diversion, it happened well after I noticed the original issue.

However, I very much HAD done what you detailed. The original bookmark HAD auto enabled and did NOT use the MDTM function. It "failed." Had been that way for a while. It failed again when I enabled MDTM. Only re-creating the bookmark seemed to solve the issue. It was after I noticed the original issue that I tried it with auto detect disabled.

Being the curious one, now that I'm into it, I wonder HOW you "automatically" detect? Does this mean that it reads the OSes date/time and offset from GMT? That should mean it's immune to the DST/EST thing here in the US, so no matter when the clock moves forward next spring, the OS will know the offset moves from 4 to 5 hours.

So I'm still not totally sure why the "detection" is actually needed. Is it because an ftpd  server works strictly in UTC, no matter what it's "local time" happens to be?

In any case, I hope I livened your day up JUST a tad...

Ah, before I read your last post, I noticed that the ahead/behind I HAD set mysteriously changed. I set it for "behind," saved and re-opened the bookmark and it was still set for "behind." BUT after I uploaded, I again checked the bookmark and it was changed on it's own back to "ahead."

So I tossed and recreated the bookmark. BINGO, files NOW seem to be correctly time stamped, matching my times. My "new" bookmark has 4 hour ahead enabled, passive and use MDTM enabled.

I did an edit to a local html file and did the sync and it WORKS AS EXPECTED.

Sure seems like the original bookmark was the issue. Which means I probably should re-do the droplet as well... the moral of the story seems to be that bookmarks can look correctly set, but cause issues.

NB: eek my toolbar arrangement is back at default, I should have done a image of the old one so I could  set it the same... oh well, not a big deal!

The time offset listed in the bookmark IS set correctly to 4 hours "ahead" (of course, part of the issue is that the GMT offset changes twice each year, but that's  another issue). And it has been enabled all along. I added "Use UTC" in addition to MDTM, deleted a folder and re-uploaded it. And in true nerd fashion, I even quit and re-launched Yummy after changing the bookmark!

Setting UTC seems to do nothing. Nothing is being shown in UTC. And I really do NOT want to have to deal with UTC!!

After tweaking the settings and re-uploading I see files showing a 4 hour offset (ahead of my time) and folders showing time of upload.

So back to the drawing board... I turn OFF the bookmark's "detect time offset." Delete and re-upload the same folder. Re-upload the folder, same thing, all files are listed 4 hours ahead while folders are listed as of time of upload.

Ah-ha, light bulb goes on. Ahead or behind is a function of what one considers the primary time... logically I am correct in saying UTC is ahead of ME, but from a UTC "perspective" I am "behind" it. So I changed the time offset setting to behind from ahead, made sure it was enabled, and deleted and re-uploaded the same folder. SAME THING, files on the server are listed as 4 hours AHEAD of my files times.

Not sure what to try next...

Straight FTP server (commercial web hosting outfit).

Ah, must have blanked on bookmarks having unique options... I enabled Use MDTM in them bookmark I use (as well as the upload droplet) but didn't enable "Use UTC" as I'm still used to the 12 hour clock.

Sync not withstanding, getting the date/time to be the same needs to happen first. So after I changed the MDTM thing in the bookmark, I deleted a folder and re-uploaded it from scratch. Again, what was uploaded seemed to take on several odd characteristics (I sent you an image to the support number).

So let's take this painful step by step if you don't mind!

Just ran into an issue I could swear I have seen discussed, but I can't find that discussion. I was in the process of uploading a site and tried to use the sync function to move the changed files after my initial upload. EXCEPT it wouldn't work because the "time" the files were tagged on the server was not the modified time of the file but the time it was uploaded AND it was offset by 4 hours in the future (which I think is the current offset time from me to GMT/UTC).

So it seemed no matter what I did, all server files were always "newer" than the files I had which were definitely "newer" than the ones on the server. AND the only UI control I see is a "maintain modification dates of transferred files" in the Transfers tab.

So I am double whammied (British term, right-o?) Still, I could swear this didn't happen a while back, I can remember sync's that went exactly as they should go.

Actually, there may be many instances where someone would WANT the local side to be the first focus... they launch Yummy with the intention of uploading a file, so the pane having the "file to upload" should be the initial focus. They finish the session by poking around the ftp server, then quit. If "last focused list" is enabled, they launch and get the "wrong"  pane as the initial focus.

IMO the only "proper"  way is to have a pref that can be set per bookmark... but I think default behavior is local focus because that's  what I suspect the majority expect.

That brings up another question that could be of some interest to some. Actual document files can also be protected via a password (other than archives containing multiple files). Say it's a tiff image, or a .mov movie file. Both of these CAN be "previewed" in YummyFTP (not so sure about YummyRecipies). If a password protected file like these are selected for previewing, does Yummy provide a mechanism for entering that password and then allowing viewing of said file?

(Jason is about to be ready to strangle me)   

Doubtful, he's a pacifist.