I'm happy to report that with 667 it is now possible to successfully use F5/F6 to copy/move files between MTP storage (e.g. phone) and PC folders. And mouse/cursor drag/drop also works, as it already previously did with 665 and 666.
So all previous fatal problems with copy/move where MTP device is the source seem to have been resolved in my Win7 x64 environment.
However I'd previously reported with betas 665 and 666 that even with a mouse/cursor drag/drop, when handling files FROM an MTP device TO a PC folder, that the "A" attribute flag bit was not set in the receiving target file's directory entry.
Well, the "A" flag problem is still not resolved in 667. No matter how the file gets copied/moved from MTP device to the target PC folder, the resulting PC file still DOES NOT SHOW THE "A" ATTRIBUTE. This is significant.
It also affects the operation of my nightly INCREMENTAL backup procedure, which looks for files with "A" attributes as the trigger to knowing they should be "archived" tonight to the backup dataset and the "A" flag then turned off.
667 - copy/move from MTP to PC does not set "A" attribute fl
Re: 667 - copy/move from MTP to PC does not set "A" attribut
Have you checked what happens if you make the copy with Windows Explorer?
Re: 667 - copy/move from MTP to PC does not set "A" attribut
Good question.
Turns out, the "A" attribute DOES NOT get set even when using Windows Explorer in a drag/drop from the MTP-connected phone to a PC target folder!
So assuming FCXE is using Explorer capability functions for MTP support, I guess the culprit appears to be Windows Explorer rather than FCXE.
Nevertheless, this is bothersome, even if it's Windows which is at fault. Would be nice if FCXE would come back in after the operations complete and mark the files with the "A" attribute anyway, as it really should have happened automatically and does happen in all non-MTP situations.
Turns out, the "A" attribute DOES NOT get set even when using Windows Explorer in a drag/drop from the MTP-connected phone to a PC target folder!
So assuming FCXE is using Explorer capability functions for MTP support, I guess the culprit appears to be Windows Explorer rather than FCXE.
Nevertheless, this is bothersome, even if it's Windows which is at fault. Would be nice if FCXE would come back in after the operations complete and mark the files with the "A" attribute anyway, as it really should have happened automatically and does happen in all non-MTP situations.
Who is online
Users browsing this forum: No registered users and 45 guests