locked
Copy/move files from camera to new-style folder links on desktop fails in surprising ways RRS feed

  • Question

  • I'm beginning to think I shouldn't have upgraded to Vista... two very bizarre and risky issues in three days (this being the second one, and really a third one as well).

    On both Vista Business x86 and Home Premium x64, using a Canon A650IS camera, the following behavior is seen:

    • Create two new "Vista-style" folder links on desktop, one to local folder (same partition as desktop folder itself), one to non-local folder (different partition).  (Doesn't affect the outcome but confirms this isn't related to crossing partition boundaries.)  Legacy lnk files from XP work just fine, but we want to test the failure mode first.
    • Take photos.  Specifically, take photos you won't miss, because if this happens to you when you aren't expecting it you'll miss them dearly as I did.
    • Plug in camera
    • Browse to DCIM folder where photos are at (NOT using "import" functionality).
    • Drag (copy) a photo to the desktop itself.
    • Notice how it a) copied OK and b) its mod date is... just now, actually.  That's the other issue: the mod date should equal the creation date as seen in the details view but no, it's gotta be different for no good reason.  In fact, if you selected the Modified column in details on the camera view you see... nothing.  No mod date at all.  How strange, how useless.  Use external tool to fix mod date to match EXIF data at least, if you care for this to work as it did, reliably, in XP.
    • Onward, then!
    • Drag a photo from the camera folder into one of the new Vista-style folder shortcuts on your desktop. Open the folder.  Note the distinct lack of your photo there (and no failure notice)!
    • Try it again.  It seems you need only do this process twice to get a special message: "Windows Explorer has stopped working", followed by a restart of Explorer and a reorg of your desktop arrangement.
    • Now for the real fun: move a photo from the camera to one of those folder shortcuts!  Observe two things: the photo disappears from the camera and is... nowhere to be found in the target folder, with no failure notice or anything... it seemed  to work but it apparently didn't.  Also, Explorer didn't crash, mainly because you can only do this little test once per photo.
    • Shake your head and wonder why the heck a broken folder link system replaced a working one.
    • If you want to be extra-crafty (or really, old-school XP), snag a copy of the "target.lnk" file in the actual folder the shortcut lives in on your desktop (you probably know what I mean if you got this far) and copy it to your desktop.  Drag photos into there, from the camera, and observe that it works just fine.
    Well, that was fun!  I've only tested this with my camera but I suspect anything that mounts this way (that are NOT assigned drive letters) could have the same problem.  Why?  Dunno.

    Upshot: Because of this SNAFU I spent half an hour trying to recover the missing photos from the SD card in the camera (the ones that I "moved" from the camera to the Vista-style link, only to see them apparently disappear), and a few more minutes writing this report.  As I re-ran the steps outlined above I learned something VERY interesting when I DOS-explored the shortcut folder the target.lnk and desktop.ini for the Vista-style shortcut live in.  There, in that shortcut's folder, was the target and ini, along with the missing (test) photos.  Well, isn't that special?  Would the casual user open a command window and root around in the desktop shortcut folders this way?  I rather doubt it, but that's about the only way you'd discover it!

    Effectively, then, if you drag a photo from the camera to a shortcut folder, it will NOT go to the destination but will instead join target.lnk and desktop.ini in the shortcut folder, safely away from view!
      It gets copied, but unless you are cmd-line savvy and understand how the new-style shortcuts work you will be hard-pressed to find out where it was copied to.

    I'll be careful not to create Vista-style shortcut folders on my Desktop because I can't really afford to play these little "Where's Waldo's photos?" games, but for any of you out there who encounter this problem, I highly recommend you open a command window and manually browse the shortcut folder with target.lnk in it.  You might find what you thought you'd lost...

    And yes, this is a bug so please add it to your bug list it if you could, Powers That Be. Thanks!

    Windows 7 Ultimate x64 beta notes: I decided to try this in my freshly-installed Win7 beta, to see what happens... well!  I created a regular folder called C:\test, then shift-ctrl-dragged it to the Desktop to make a shortcut.  Ok, shortcut is there but if I double-click it it doesn't even open, instead failing with a "not found" error.  Very strange!  This does NOT happen in Vista.

    So I created the test folder elsewhere... seems like as long as the actual folder is at least one folder deep it's OK... a shortcut to C:\x\test worked just fine, whereas C:\test fails miserably.  Shortcuts to firstorder folders on other drives (e.g., H:\test) work fine right away.  Very weird, but hey, that's a beta for you... someone should probably look into this though.

    After sorting that out, I ran the same steps I did in Vista and got the same exact results in Win7 (right down to the same "crash Explorer" effect).  Being as how I had never even connected the camera to Win7 until just now, and it's a different computer, I'd say that's a pretty solid verification test of this, at least for this camera (using standard Canon firmware I might add).


    Monday, January 12, 2009 7:09 PM

Answers

  • If this is supposed to be "works as designed" then this driver was designed poorly.

    The camera is less than a year old.  Vista is a few years old.  I fail to see the "old device" connection.  Alternate camera firmware which is VERY current is affected in the same way.

    This is not the camera, it is a deficiency in the driver.
    • Marked as answer by Marty F Monday, February 9, 2009 7:36 AM
    Monday, February 9, 2009 7:36 AM

All replies

  • Hi,

     

    Regarding the Modified Time behavior, in Windows Vista, the first modified time should be the moment that the picture was deployed into the computer. You may check some system built-in pictures. The Created Time will be the date it is created, and the Modified time will be the moment you install the system. They should be different.

     

    There may be some issues in Windows Explorer on your computer. I suggest that you reboot to Safe Mode and test the above behaviors.

     

    If the issue persists in Safe Mode, I suggest that you try to test this issue on another Windows Vista computer if it is convenience.

     

    If there are not other Windows Vista computers available, I suggest that you make a clean parallel installation on another partition on one of the Windows Vista computers, and check if the issue persists.

     

    If this behavior occurs in the clean system, we will consider this is a compatibility issue. I suggest that you try to drag a local picture into the shortcut. If it works properly, the built-in card reader driver in Windows Vista may be not compatible with your Cannon camera.

     

    Regarding the Windows 7 question, I suggest that you post here:

     

    http://social.technet.microsoft.com/Forums/en-US/category/w7itpro/

     

    Tuesday, January 13, 2009 8:52 AM
    Moderator
  • As described above, I've already confirmed this behavior in two different installations of Vista (on two different machines) as well as the Windows 7 beta.  Same anomalous behavior on all three installs.  (As for the other possible Win7 bug, I'll look into that separately.)

    Note that the installation of Win7 in particular is almost completely pristine, straight from the beta DVD.

    If the card is directly read via a card reader it works fine, mod dates are correct (creation dates on the camera are of course identical).  It read via the Canon USB interface (as provided by default by Windows) the mod dates are all empty and but the creation times (on the camera) are correct.  When copied, of course, the creation times change, but the mod times get set to the same value as the new creation time.

    This behavior never occurred in Windows XP, using the same methodology.  This suggests reduced and/or broken functionality for this interface in Vista and Win7.  Furthermore since this is typically administered via a generic Mass Storage interface I suspect this would be the case for most any camera and possibly other such devices as well (I don't have other such devices handy to test with though).

    Tuesday, January 13, 2009 5:43 PM
  • Hi Marty,

    Have you installed same application on all of the systems, for example, anti-virus program? If the issue does not occur when you just installed the system and do not install anything else, the issue should be caused by the application that are installed on all the computers.


    Arthur Xie - MSFT
    • Marked as answer by Arthur XieModerator Wednesday, January 21, 2009 9:29 AM
    • Unmarked as answer by Marty F Thursday, January 22, 2009 11:57 PM
    Tuesday, January 20, 2009 9:48 AM
    Moderator
  • Yep, Windows 7 with not even an antivirus package installed STILL does this, and the behavior is still the same as seen in Vista.

    On closer examination it appears images explored via the Removable Storage -> DCF interface also have very different properties sheets from those when explored from, say, the desktop.  I see three tabs: General, Resources and Details, none of which even mentions a mod date.  The General and Details tabs are much more comprehensive on the computer (or when the storage media is plugged into a USB card carrier versus via the camera interface driver as above - note this camera driver is from Microsoft, not from Canon).

    Friday, January 23, 2009 12:26 AM
  • Hi Marty,

    The first modified time may be the time that the file is deployed on the computer as a computer. We find that on our computers, the created time of the built-in pictures is the time that this version Windows Vista installation is produced, but the modified time is the time that we installed these systems on our computers. You may also find that on some files the modified date is earlier than the created date. This may be caused by the mechanism when the file is created.

    We have noticed that this behavior would cause confusion for many users. We are considering report this issue and hope that this function will be changed in later Windows systems.


    Arthur Xie - MSFT
    Wednesday, January 28, 2009 2:56 AM
    Moderator
  • Arthur Xie said:

    Hi Marty,

    The first modified time may be the time that the file is deployed on the computer as a computer. We find that on our computers, the created time of the built-in pictures is the time that this version Windows Vista installation is produced, but the modified time is the time that we installed these systems on our computers. You may also find that on some files the modified date is earlier than the created date. This may be caused by the mechanism when the file is created.

    We have noticed that this behavior would cause confusion for many users. We are considering report this issue and hope that this function will be changed in later Windows systems.


    Arthur Xie - MSFT


    That's interesting, but what does it have to do with *this* problem?  That's always been the case with any normal installation or copy from any media that stores the mod date: the mod date would be set to whatever the mod date is on the source media, and only the creation date would vary (the access date would vary too, but that's not very useful to people).

    The issue I've reporting here is that the generic "Removable Storage" driver for cameras and such from Microsoft in Vista and beyond no longer acknowledges the modification date of the files on the removable storage device (camera, in this instance).  In fact, this driver doesn't appear to acknowledge the modification date at all in its interface nor when copying items from the camera to the computer.  The data is definitely on the device and in fact was always correctly transported in XP.  In Vista and Win7 the mod date on the camera (in this case) isn't being read by your driver and that data is ignored during the copy process as well, and is instead replaced with whatever time the file is being copied.

    Note again: if the media is directly plugged in it is NOT handled through the Microsoft camera driver and works as expected (as it always has).  However, that's just a work-around: the Microsoft camera removable storage driver remains broken in this regard.

     

    Wednesday, January 28, 2009 3:39 AM
  • The camera driver built in Windows Vista is a general camera driver. In Windows 7 beta the built-in drivers are the same as in Windows Vista. Therefore you got the same behavior.

    It seems that this driver is not fully compatible with your camera. We hope that Canon could release compatible driver specially for Windows Vista, Windows 7 beta and later versions.


    Arthur Xie - MSFT
    Thursday, January 29, 2009 2:47 AM
    Moderator
  • Arthur Xie said:

    The camera driver built in Windows Vista is a general camera driver. In Windows 7 beta the built-in drivers are the same as in Windows Vista. Therefore you got the same behavior.

    It seems that this driver is not fully compatible with your camera. We hope that Canon could release compatible driver specially for Windows Vista, Windows 7 beta and later versions.


    Arthur Xie - MSFT


    No.  The default Windows camera driver in XP worked fine: Canon never released a specific XP driver so it used the Microsoft generic driver then as well.  As described above, the default driver in Vista and (currently) Win7 has bugs when compared to the same Microsoft generic driver in XP.
    Thursday, January 29, 2009 3:32 AM
  • Yes, I know that it works in Windows XP. However, the default driver in Windows Vista is different between the driver in Windows XP. It is an upgraded driver. Some old devices may be not compatible. Currently most of the built-in drivers of Windows 7 beta are the same with Windows Vista. Therefore the issue still occurs in Windows 7 beta.


    Arthur Xie - MSFT
    • Marked as answer by Arthur XieModerator Monday, February 9, 2009 7:16 AM
    • Unmarked as answer by Marty F Monday, February 9, 2009 7:36 AM
    Monday, February 9, 2009 7:15 AM
    Moderator
  • If this is supposed to be "works as designed" then this driver was designed poorly.

    The camera is less than a year old.  Vista is a few years old.  I fail to see the "old device" connection.  Alternate camera firmware which is VERY current is affected in the same way.

    This is not the camera, it is a deficiency in the driver.
    • Marked as answer by Marty F Monday, February 9, 2009 7:36 AM
    Monday, February 9, 2009 7:36 AM