Show icon overlays for Mozy backed-up files

[grindax]

.

[j_c_hallgren]

Funny that you should mention this...as I tried out the free vers of Mozy some time ago and did a backup and then realized that I didn't want the system overhead so turned off the process...and then forgot about it...looked at some files in Win Expl later and wondered what those green checks and red x's were... Duh! It's Mozy status flag..

Anyway, yes, you're right that XY doesn't seem to show these...I have Cache specifc icons & Icon Overlay & Show specifc icons all turned on, and Use Generic icons off...

For ref, here's what one file looks like in Properties in both WE & XY:

Win Expl screenshot

SS - 09-25-09 @ 22-49-06001.jpg (8.38 KiB) Viewed 2743 times

XY screenshot

SS - 09-25-09 @ 22-49-51001.jpg (8.22 KiB) Viewed 2743 times

Note also the difference in the base icon itself...This file is for a tax preparation software and the desktop icon for 2004 & 2005 vers was the flag thingy and in 2006, just a green box...here's what shows in File Types which is not consistent either as you can see:

[admin]

Funny that you should mention this...as I tried out the free vers of Mozy some time ago and did a backup and then realized that I didn't want the system overhead so turned off the process...and then forgot about it...looked at some files in Win Expl later and wondered what those green checks and red x's were... Duh! It's Mozy status flag..

Anyway, yes, you're right that XY doesn't seem to show these...I have Cache specifc icons & Icon Overlay & Show specifc icons all turned on, and Use Generic icons off...

For ref, here's what one file looks like in Properties in both WE & XY:

SS - 09-25-09 @ 22-49-06001.jpg

SS - 09-25-09 @ 22-49-51001.jpg

Note also the difference in the base icon itself...This file is for a tax preparation software and the desktop icon for 2004 & 2005 vers was the flag thingy and in 2006, just a green box...here's what shows in File Types which is not consistent either as you can see:

So the Properties look different in WE and XY? Hm, I did not know this was even possible! This dialog is made by the Shell, not by XY... Stumped.

[grindax]

.

[admin]

Checking again through the files on my local filesystem which are synchronised with Dropbox (and which also have overlays), I notice that for most of them the overlays work OK in XYplorer, but for a group of them, in particular shortcuts to web URLs (ie. ending in .url), the overlays don't display in XYplorer. Opening up a Windows Explorer window to the same location shows all of the overlays.

I guess this means:

(a) there must be more than one way that overlays can be associated with files
(b) there is at least one way that XYplorer doesn't recognize

Yes, I agree with the analysis. (Currently no time to research this, though.)

[arirish]

I've enabled the option called 'Show icon overlays' and notice that this works fine for files backed up to Dropbox (green ticks are displayed on file icons).

Funnily enough I've been muttering quietly to myself about the lack of Dropbox overlays for a while. Today, I stumbled across your post, thought to myself 'Show icon overlays... where's that then?', had a look through the config, found it, and BAM! There they are.

So thanks for that

[grindax]

.

[admin]

Furthermore, for those files where the overlays are displayed, they don't auto-refresh. For example, if I drop some files into my Dropbox folder, the overlay shows the little blue synchronizing icon. After being uploaded to Dropbox, the overlays don't change to the green check marks. I have to manually refresh. Even though I have auto-refresh turned on.

After the images should have changed but did not, please run this through Address Bar.

Code: Select all

text "<get debuglog>";

Do you see "SHCNE_UPDATEIMAGE" with a timestamp that matches the event?

If yes, I know what to do to fix this.

[grindax]

.

[admin]

After the images should have changed but did not, please run this through Address Bar.

Code: Select all

text "<get debuglog>";

Do you see "SHCNE_UPDATEIMAGE" with a timestamp that matches the event?

If yes, I know what to do to fix this.

Not sure I understand how to do this properly. I've pasted that text into the address bar and hit Enter, but I just get a message saying
Couldn't find location: C:\Program Files\XYplorer\text "<get debuglog>";

Sorry, my mistake, preprend :: like this:

Code: Select all

::text "<get debuglog>";

[grindax]

.

[admin]

OK, now I just get a window that opens up that contains the text
<get debuglog>

and nothing else.

Are you using the latest beta version? You should for this test to work...

[grindax]

.

[admin]

Alright, I've tried again with the latest beta. I started XYplorer, copied in one new file into the Dropbox folder and waited for the sync to finish. Then, when the overlay was still showing the blue syncing icon, ran the script. Now I see all the events, but none to do with updating images. Here is what I see (with the pathnames and filenames removed):

09:41:22.232 >> 2: ¿
09:41:22.716 >> SHCNE_UPDATEITEM, 1=38993964, 2=0
09:41:22.716 >> SHCNE_UPDATEITEM, 1=38993964, 2=0
09:41:22.716 >> SHCNE_CREATE, 1=38993964, 2=0
09:41:22.716 >> SHCNE_CREATE: | |
09:41:22.716 >> SHCNE_FREESPACE, 1=38993964, 2=0
09:41:22.716 >> SHCNE_UPDATEITEM, 1=38993964, 2=0
09:41:22.716 >> SHCNE_UPDATEITEM, 1=38993964, 2=0
09:41:22.716 >> SHCNE_CREATE, 1=38993964, 2=0
09:41:22.716 >> SHCNE_CREATE: | |
09:41:25.560 >> SHCNE_UPDATEITEM, 1=40763436, 2=0
09:41:25.560 >> SHCNE_UPDATEITEM, 1=40763436, 2=0
09:41:25.560 >> SHCNE_UPDATEITEM, 1=40763436, 2=0
09:41:25.560 >> SHCNE_UPDATEITEM, 1=40763436, 2=0

Looks like SHCNE_UPDATEITEM is the event. Four times within the same millisecond, well... I still need to another debug log from you in the next version, which will give me the last missing puzzle piece.

[admin]

Alright, I've tried again with the latest beta. I started XYplorer, copied in one new file into the Dropbox folder and waited for the sync to finish. Then, when the overlay was still showing the blue syncing icon, ran the script. Now I see all the events, but none to do with updating images. Here is what I see (with the pathnames and filenames removed):

09:41:22.232 >> 2: ¿
09:41:22.716 >> SHCNE_UPDATEITEM, 1=38993964, 2=0
09:41:22.716 >> SHCNE_UPDATEITEM, 1=38993964, 2=0
09:41:22.716 >> SHCNE_CREATE, 1=38993964, 2=0
09:41:22.716 >> SHCNE_CREATE: | |
09:41:22.716 >> SHCNE_FREESPACE, 1=38993964, 2=0
09:41:22.716 >> SHCNE_UPDATEITEM, 1=38993964, 2=0
09:41:22.716 >> SHCNE_UPDATEITEM, 1=38993964, 2=0
09:41:22.716 >> SHCNE_CREATE, 1=38993964, 2=0
09:41:22.716 >> SHCNE_CREATE: | |
09:41:25.560 >> SHCNE_UPDATEITEM, 1=40763436, 2=0
09:41:25.560 >> SHCNE_UPDATEITEM, 1=40763436, 2=0
09:41:25.560 >> SHCNE_UPDATEITEM, 1=40763436, 2=0
09:41:25.560 >> SHCNE_UPDATEITEM, 1=40763436, 2=0

Looks like SHCNE_UPDATEITEM is the event. Four times within the same millisecond, well... I still need to another debug log from you in the next version, which will give me the last missing puzzle piece.

Sorry, you were too late. I had to terminate the debug log phase. I will look at this again in a later version.