Print

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

[Peter Engrav]

I'm seeing unfortunate behavior that I think used to work.  If I use Rename Move & Copy Files on a file that turns out to be read-only (either the file is set to read-only only or the share is read-only or whatever) MC gives a nice error but it also updates the filename property in the library entry. Hence it's now disconnected from the actual file. I just broke several hundred files this way and am now stuck in a very manual cleanup process.

Also (now suddenly this is a feature request, I suppose) I haven't been able to find any feature (either "reconnect broken links" or "find duplicates" or such) that would help clean up after something like this happened. In fact there doesn't seem to be any way to "connect" a library entry to an existing file.

[AoXoMoXoA]

I haven't been able to find any feature (either "reconnect broken links" or "find duplicates" or such) that would help clean up after something like this happened. In fact there doesn't seem to be any way to "connect" a library entry to an existing file.

Using "Rename File Form Properties" again, at the top-most pull-down select "Update Database to Point to New Location (no filename, move or copy perfiormed)", now point MC back to the location where the files actually reside on the hard drive. This should re-connect them to the library with all their previous data intact.

[Peter Engrav]

(Thanks for the pointer to the recovery step, should probably have found that on my own).

I also just discovered that if you have files named, say, A, B, C and you apply a batch rename that's going to call them instead C, B, A, you get errors. Whichever of A or C tries to rename itself first brings up the Windows "Er, there's already a file called that, would you like to Move & Replace, Make a Copy, Not Move" Dialog after which you're in a similar disconnected state. I seem to recall that this used to work as well, that MC was clever enough to realize that the new names from a batch rename included some duplicates from the old names list and (I presume) rename those files twice, once to a temp "out of the way" name.

[MusicHawk]

>> if you have files named, say, A, B, C and you apply a batch rename that's going to call them instead C, B, A, you get errors

I've encountered this a lot, probably because I've tried many different naming conventions over the years and have 60K+ files to deal with. I'm not aware of any logic in MC that triggers multiple renaming passes.

My solution is to just run the Rename process as many times as MC requires before it stops giving errors. I'm typically working with a subset of tracks, in a view by artist or similar, and getting the filename correct involves a complex Rename expression because my file path/name uses Artists (a custom field), Genre and Rank (another custom field) and certain manipulations.

Each Rename pass gets at least some files renamed as I desire. 99.9% of the time with multiple runs MC eventually properly renames all the folders/files. In the 0.1% case I give up and manually rename by editing the track's filename field. Then I run Rename one more time to be sure MC is happy with my change.

Also, Rename can clean up filenames with (1) or similar MC changes trigged by dupes that no longer exist so it's a big help cleaning up. However -- caution -- if a dupe really exists, multiple Rename runs can sometimes flip the (1) from file to file, then back again, forever. This requires manual intervention.