Print

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

[BryanC]

I recently had to restore a library backup due to malfunctioning hardware. Between the time of the last library backup and when my hardware failed I had cleaned up some capitalization problems in my library and subsequently used RM&C to update the filenames.

After restoring the backup I reran Auto-Import and was a bit dismayed to find that none of the renamed files were re-imported into MC (and no "broken links" were fixed either). I tried to play one of the files that had been renamed and unsurprisingly MC complained that it could not find it, as the [Filename] capitalization differs from my filesystem.

The "automatic" method to fix this would be to enable "fix broken links", allow MC to remove the "missing files" and then re-import the new case'd files, however this would lose all of my playback stats/playlists etc. The other option is to hand revert my filenames on the filesystem to match MC's library, or redo all of my changes in the MC library to match the filesystem, neither of which I wish to undertake.

Does anyone have any ideas how I can get out of this mess? I've thought about transferring everything to a case insensitive OS so that MC can access and rename the improperly case'd files to match its database using multiple RM&C steps, but there has to be a better way.

[RemyJ]

What about doing a tag update on all files using an obscure tag?   The ones that MC can't tag because the name's different should be flagged as a broken link now yes?

[BryanC]

What about doing a tag update on all files using an obscure tag?   The ones that MC can't tag because the name's different should be flagged as a broken link now yes?

Good idea, thanks. Still a lot of manual labor to retag properly, but that will at least narrow the scope.

[RemyJ]

Thinking more about this...   Wouldn't "Fill Properties from Filename"  do what you want or does that not work if only the case differs?
The other thing you could do is to set the library fields for those files to something stupid then run FPfF.

[mwillems]

I recently had to restore a library backup due to malfunctioning hardware. Between the time of the last library backup and when my hardware failed I had cleaned up some capitalization problems in my library and subsequently used RM&C to update the filenames.

After restoring the backup I reran Auto-Import and was a bit dismayed to find that none of the renamed files were re-imported into MC (and no "broken links" were fixed either). I tried to play one of the files that had been renamed and unsurprisingly MC complained that it could not find it, as the [Filename] capitalization differs from my filesystem.

The "automatic" method to fix this would be to enable "fix broken links", allow MC to remove the "missing files" and then re-import the new case'd files, however this would lose all of my playback stats/playlists etc. The other option is to hand revert my filenames on the filesystem to match MC's library, or redo all of my changes in the MC library to match the filesystem, neither of which I wish to undertake.

Does anyone have any ideas how I can get out of this mess? I've thought about transferring everything to a case insensitive OS so that MC can access and rename the improperly case'd files to match its database using multiple RM&C steps, but there has to be a better way.

Have you tried using the fourth option in the upper left corner of the RM&C  window("update database location" or something like that?).  You can use that to repair broken database entries so they point to the correct files, and I think it should work for case issues too.  This is assuming you can readily identify which files are affected.

Something worth being aware of (that you probably already know, but it gigged me once in a similar situation):  if you're accessing the files on a network share via Samba you won't be able to do anything with case because Samba is case insensitive even when both sides are Linux machines.  I once had a "Nick Cave and the Bad Seeds" directory as well as a "Nick Cave And The Bad Seeds" directory on a linux drive shared via SMB, and only one of those directories was actually reachable from client computers because they "collided."

[HaWi]

Have you tried using the fourth option in the upper left corner of the RM&C  window("update database location" or something like that?).  You can use that to repair broken database entries so they point to the correct files, and I think it should work for case issues too.  This is assuming you can readily identify which files are affected.

Something worth being aware of (that you probably already know, but it gigged me once in a similar situation):  if you're accessing the files on a network share via Samba you won't be able to do anything with case because Samba is case insensitive even when both sides are Linux machines.  I once had a "Nick Cave and the Bad Seeds" directory as well as a "Nick Cave And The Bad Seeds" directory on a linux drive shared via SMB, and only one of those directories was actually reachable from client computers because they "collided."

That's interesting. Is this true for NFS as well? I am using NFS shares as they appear to be less hassle with auto-mounting on my iMac and I might have seen this capitalization problem as well but I am not sure.

[RemyJ]

That's interesting. Is this true for NFS as well? I am using NFS shares as they appear to be less hassle with auto-mounting on my iMac and I might have seen this capitalization problem as well but I am not sure.

NFS is case sensitive.  Unless of course you're using a Windows NFS client in which case you have to mess with nfs settings to control whether it's case sensitive or not.  I've been using it for years with MC Linux <> Linux and never had an issue.

[zybex]

Samba case sensitivity is configurable in smb.conf, and the default is case-insensitive. NFS is case-sensitive by default, but also configurable.

smb.conf:
case sensitive = true
default case = lower
preserve case = yes
short preserve case = yes