Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[varian93]

I've been using the F6 shortcut for Rename, Move, & Copy regularly for over a year now (using the exact same preset) when suddenly I started to notice some strange behavior.

It would report success & indeed the files would be moved, however they would not be renamed correctly. It's been happening more and more frequently. I never thought to bother to check if they were not renamed at all or only partially until just now, so I can not say.

In this event I'd simply press F6 on the exact same files again & the same preset would already be selected and rather than the "New" column listing <no change> it would show the correct renaming. I'd click OK & upon verification the files were correctly renamed.

At the same time that this behavior manifested I noticed that the files in the database would still point to the old location. I'd select Tools, Import, Run Auto-Import Now & when doing so the database would update correctly, but there would be duplicates of the files that I recently ran Rename, Move, & Copy on. I've attached a screenshot of an example of this result. Sometimes the duplicates are as the example and point to the exact same location. Other times one entry points to the original location (where the file no longer is) while the other entry points to the correct & current location. I could not find any way to remedy it other than to restore a recent backup of my library and run auto-import again. It would then be correct with no duplicates.

Since this all began after I run Rename, Move, & Copy I must close MC then reopen it and run Auto-Import Now to correctly update the files that I've just ran Rename, Move, & Copy on with no duplicates or issues.

I've done a search on the forum regarding "duplicates" & couldn't find any information.

Please note:

1. The Rename, Move, Copy function not correctly renaming the files does not always occur. However it happens enough to be troubling.

2. At the same time that #1 appeared Rename, Move, Copy stopped updating the database without me having to manually "run auto-import now".

3. #2 seemed to always result in duplicate entries in the library so my remedy was to close MC in between Rename, Move, Copy & running auto-import.

4. This issue has been occurring for some months now. I hesitated to report it immediately thinking if it was something I was doing that I'd figure it out or if was a fault of MC then JRiver would. It seems neither of us has...

5. I'm using MC 25.0.31 64-bit.

Any input would be greatly appreciated.

Thank you,
Varian

[varian93]

So really no one has any suggestions or ideas?

I'm now using MC 25.0.98 64 bit & the error yet persists.

[JimH]

Are any files or folders or parent folders read-only?

[varian93]

I checked and this is what I found.

The answer isn't clear.

I'm using Windows 10 and the drive is formatted NTFS. I don't know if it's a Windows thing or NTFS thing, but every FOLDER has the following verbatim OS wording for the read only attribute: "Read-Only (Only applies to files in folder)" & the attribute is applied. When I directly check the FILES individually they are all NOT marked as "Read Only".

In the past it has always been this way. I've never understood why or what exactly it meant. If I manually go to a folder and uncheck the "Read-Only (Only applies to files in folder)" attribute and apply it, a long amount of time and much hard drive churning ensues. After which I recheck the folder's properties and it has reverted to having the attribute "Read-Only (Only applies to files in folder)" applied.

I know that's not clear at all... I hope it's helpful.

[glynor]

Read-only status of folders has a "special meaning" on NTFS, and it is typically ignored by the system:
https://support.microsoft.com/en-us/help/326549/you-cannot-view-or-change-the-read-only-or-the-system-attributes-of-fo

Permissions on the folders (or ownership) is much more likely to be the cause. Take ownership of the entire directory tree and reset all of the disk permissions to a known good state (and apply the changes to the item and all child items).

[varian93]

I checked the permissions & ownership of the entire directory tree of the disk and indeed found that the group "Users" did not have permission to "modify" or "write". All other groups had "full control". I changed it so that all groups had "full control" and did a test run. It renamed the files correctly the first time through. I also did not have any duplicates in the library.

This test seems to prove that the advice fixed the issue. The problem did not always present itself 100% of the time, so it yet might persist. However I do feel mostly confident that this fixed the issue since as of late it was happening nearly every time.

If it begins to occur again, I'll check to make sure that the permission have not somehow been modified and if they haven't, post again.

Thanks everyone.

[varian93]

This issue has manifested again. I verified that all of the security setting profiles give "full control" to the entire directory tree structure.

After a lot of testing of many different scenarios I believe I have determined an exact cause. The reason it appeared to work for me when I reported success is that my test did not include one of the necessary variables to cause it. It was coincidence that the faulty test was conducted after the security changes had been made.

It seems that ANY mp3 or flac downloaded from bandcamp falls victim to this. I don't commonly use any other formats, so did not test them. I assume they are all suffer similar results. I was able to identify the cause by having the issue reappear a day after I reported that it was resolved. It happened with a download from bandcamp. Frustrated I tested a few of my own old rips that were waiting to be organized and the issue did not present itself. I was a little baffled and a day or so later I realized what the difference was.

I then proceeded to download a few of my previous purchases from bandcamp and they all behaved the same. I took a few more samples of my own rips and again they worked perfectly. I even tried downloading the bandcamp files to the same location as my own rips, that did not fix the issue.

Again I took several random samples out of my "waiting to be organized" audio archive and the issue did not present itself.

I did note that MC correctly creates the directory structure, which is based on the tags that are also used in the renaming of the files. However it will make no changes to the original filenames. If I use the "Rename, Move, & Copy" feature on the same files a second time it does rename them correctly.

I can not think of anything that bandcamp could be doing to their files that would make MC behave this way.

These rips of mine that I tested were ripped some time ago using Exact Audio Copy.