The Windows Explorer in Windows 7 doesn't implements this correctly. Some preview handlers maintain a file lock while the file is being previewed. The Windows Explorer sends a file unload command to the previewer but immediately issues a new load command, without giving time to effectively unload the file, and so fail to get write access to the file. The only PDF preview handler that seems to free the file on time is the one included in the Foxit PDF Reader.
In Windows 8.x, despite the fact there is no longer the possibility to have both the details pane and preview pane open at the same time, it properly unloads the previewer when the file properties dialog is invoked (the metadata properties can then be edited from this dialog details tab sheet).
Windows 10 is even smarter and unloads the previewer when it detects any write access request to the previewed file.
Anyway, the
PDF-ShellTools preview handler tools extension also has a metadata edit pane, you can use to edit the properties. Because it handles the file accesses internally, it is able to properly manage the situation.
Take note that when using compliant PDF preview handlers, e.g. the one from the Foxit PDF reader, the same file access problem will show up, when editing the properties from the Windows Explorer details pane, if the PDF-ShellTools preview handler tools is charged with its metadata pane open (i.e. if editing from the Windows Explorer details pane, make sure the previewer is charged with its details pane closed).
