File Exists problem with certain files (XML?)

Hi there

I've set up a recurring item in my Transfer Queue which I run occasionally to update only those files on the remote ftp server that have been updated locally.

This seems to work well for most files, with only updated files being transferred, but there is one particular file -- with name "folders.xml" -- that doesn't seem to update properly on the remote server.

What happens with this file is that the remote date/time appears to be updated to the most recent queue run time -- the same or similar as other files that have been transferred in that run -- but the actual file content is unchanged -- when I download the remote file and view it locally I can see that it is the old version, not the new version.

Any idea why that would be?

I've tried with the File Exist Rule set to use the hash function, and also set to use the default (non hash) rule, with the same result -- the date/time of the remote folders.xml file seems to be updated but its content does not.

Any ideas?

Thanks,

Mike

Hello ...

Please provide all the necessary information to reproduce the problem.

Thank you.
Regards,
SmartFTP

I just reproduced this with a jpg as well.

What I'm doing is:

(1) Local folder with 1 jpg in it.
(2) Use Transfer Queue in SmartFTP. Stop Queue.
(3) Drag local folder onto remote folder. Folder appears in Queue as a new job, but doesn't run.
(4) Right click on new queue job (a folder), and set Schedule > Monitor local file.
(5) Play Queue. Jpg transfers to remote.
(6) Edit local jpg with visible differences -- put in lots more details. Resave as jpg. Note new size.
(7) Queue job runs again to transfer edited jpg to remote folder... should overwrite remote copy (File Exists set to hash function).
(8) Refresh remote folder view... remote time/date is now transfer time and size is now that from (6). Seems like it has transferred OK.
(9) Download remote jpg to different local folder.
(10) View downloaded jpg from (9).

Do you see the edits you made in (6) in the newly downloaded version from (9)/(10)? On my system, I do NOT. It's the old version I see. But the filesize is the same as the edited version.

Weird.

You may need to repeat (6) to (10) to see what I'm seeing at least once.

Mike

Update:

This only seems to happen when the file size *increases* by the edit in step (6) -- which it would do following my instruction to add lots more detail into the jpeg. When the file size increases, the edited file does not seem to transfer, but the date/time of the remote file IS changed, and the size of the remote file takes on the edited size -- despite not having the edited content.

This must be incorrect behaviour?

When the file size *decreases* in step (6), the file does seem to transfer as expected, with the remote file properly updating in all respects.

Mike

Update 2:

When the local jpg file itself is dragged onto the remote folder to set up the queue item (monitored again) -- and not the folder containing the jpg as first instructed -- so that the queue shows a file and not a folder -- everything seems to update fine whenever an edit is made to the jpg, both increasing and decreasing in size.

Mike

Hi mb

Are you able to reproduce this behaviour at your end?

Cheers,

Mike

Just wondering... is it your policy to ignore reports of (potential) bugs from non-licensed users?

Mike

OK it seems that maybe it's *not* your policy to ignore bug reports from unlicensed users, but just not to admit that there was a bug, and to fix it silently without reply or acknowledgement. I just upgraded to the most recent version and this problem has mysteriously gone away. And the version I was on previously was less than two months old, so....

Anyhow, nice to see this working properly now.

Mike