View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0008548 | MMW v4 | DB/FileMonitor | public | 2011-10-19 21:37 | 2011-11-06 23:56 |
| Reporter | peke | Assigned To | |||
| Priority | urgent | Severity | block | Reproducibility | sometimes |
| Status | closed | Resolution | not fixable | ||
| Product Version | 4.0 | ||||
| Target Version | 4.0 | ||||
| Summary | 0008548: On DB Upgrade Permitions are inherited instead updated/renewed | ||||
| Description | In some cases when MM.DB from c:\user\<username>\AppData\Local\MediaMonkey have read only permitions for active user problem arises as copying c:\user\<username>\AppData\Local\MediaMonkey\mm.db -> c:\user\<username>\AppData\Roaming\MediaMonkey\mm.db also inherit MM.DB permissions. That results in MM not being able to update library to latest version. Solution would be to either: 1. Manually change permissions to allow MM write access into file by either adding "Everyone" or "Users" in user list with Full Access rights after MM throws error or 2. copy c:\user\<username>\AppData\Local\MediaMonkey\mm.db to c:\user\<username>\AppData\Roaming\MediaMonkey\mm.db.old and use that for Copy/Paste to newly created c:\user\<username>\AppData\Roaming\MediaMonkey\MM.DB which will result in slower update of DB but will also include maintain option. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
File itself is not read only but security tab on file showed that active user have only read access. Something on user system set that permissions, AV(False Positive)/UAC/Hardware itself which locked all files used by MediaMonkey.exe into virtualization environment. We will never know what caused it but know what fixes it. EDIT: User do not have MM3 on the system |
|
|
Before making any changes, I'd like to better understand what's going on. User should always have write access to his personal folder, in case this isn't true, it's something very strange and I'm not really sure we even should try to fix it. So, I'm setting target to 4.1 and assigning to Peke to try to find the exact reasons why this happens. Unless we find out more, I'd rather not do anything about it. |
|
|
As explained on IM exact reason is "Specific to user system permission settings" like with 0007829 solution should be same. |
|
|
It is easy to replicate exactly like with 0007829 Resetting to new for MM 4.1 inclusion in case of more reports. |
|
|
I cannot replicate, what are the exact steps? |
|
|
I uploaded to FTP pictures of One of way to get error using specific set of permissions in Security Tab of MM.DB NOTE: MM is started as Normal User not using Run As administrator NOTE2: After deleting such set MM.DB (assuming that user is administrator) MM starts correctly |
|
|
I understand that one can change permission to read-only for the MM.DB, but are you really able to replicate it? Note that this is not the same as 0007829, because in case 0007829 there were known steps to replicate: http://www.ventismedia.com/mantis/view.php?id=7829#c27658 But in this situation even if I run MM as administrator then it always creates MM.DB with full access permissions also for the standard user. Also based on your screenshots it looks that the permissions for your MM.DB file were changed manually or by another app as they are in black and not gray (default). |
|
|
You are right, I was changing permitions manually to simulate SOME app change of permissions to MM.DB and generate same look as I was found on users PC. Like you pointed and like Jiri pointed in 0008488 there is nothing we can do until we gather more info. |
|
|
Closing as user specific issue. No additional reports till 1455 |
