Topic: Library folder limitations between operating systems (Read 13445 times)

Awesome Donkey · « **on:** January 21, 2014, 03:56:21 pm »

Okay, I've found a potential issue that's attributed to both the Windows and Linux versions of Media Center (probably Mac too, I'll try it in a few weeks when/if I find the time to redo my Hackintosh) when you have a library stored on another drive that's read between different operating systems (seemingly due to file system limitations of the other operating systems).

I noticed that after when I ran the Rename, Move, & Copy Files feature to organize my music library in the Windows version, that some albums weren't showing up at all when the music partition was mounted under Ubuntu while they appeared fine under Windows. After looking in MC for them in Ubuntu, I opened up Nautilus and saw not all .flac files were being detected by the Linux file system. After some more investigation, I've found the culprit... albums/songs/artists that begin with dots and/or multiple dots (e.g. ...Hits) don't show up at all under Debian/GNOME-based operating systems (probably all others too) because the file system treats them as hidden files. Examples of missing albums under Ubuntu that show up fine in Windows are (examples in this case being Phil Collins albums)...

...But Seriously
...Hits

It's not a bug with the Linux version. In reality, it's not really a bug at all (UNIX/Linux file system limitations it seems - so it's likely to affect Mac too) and wouldn't be an issue if MC was still Windows-only.

Hendrik · « **Reply #1 on:** January 21, 2014, 04:31:00 pm »

Personally I would think its a bit silly if my files stopped showing periods, just because some other OS considers all files starting with a period a hidden file.
Its not that the file system is actually incompatible, or that periods are a forbidden character (like ? on Windows is) - its just that any file starting with a period is considered "hidden" on Linux, and most likely also Macs.

I'm sure we can teach MC19 to also import hidden files, so they show up in your library again. But of course that doesn't "solve" the problem browsing to them in a file explorer.

Awesome Donkey · « **Reply #2 on:** January 21, 2014, 04:33:14 pm »

Yeah, it's pretty annoying indeed since regardless of the hidden folders/files being shown by the file manager, MC won't even attempt importing them. Is there any room for customization here for the Rename, Move, & Copy Files to strip dots if I want it to or some other type of short-term workaround?

MrC · « **Reply #3 on:** January 21, 2014, 05:29:39 pm »

The dot file-ignoring was done I believe to avoid issues with Android, but it seems a heavy hammer.

Pedantic FYI: Dot files are not ignored by any Unix OS kernel or filesystem - this is a convention established long ago, and written into certain utilities (such as ls(1), shells, etc.). There is nothing special about dot files, with the exception of "." and "..", which is handled by the kernel.

MC should at least issue warnings and an explanation about why these files not being imported. My general feeling is that MC should behave like other utilities and not import files that begin with a single dot, since these could very well be temporary files such as lock files, swap files, etc., but it should consider importing non-data files and folders with more than a single dot, since it would be very rare for a temporary file to begin with two or more dots.

Awesome Donkey · « **Reply #4 on:** January 21, 2014, 05:35:05 pm »

Quote from: MrC on January 21, 2014, 05:29:39 pm

MC should at least issue warnings and an explanation about why these files not being imported. My general feeling is that MC should behave like other utilities and not import files that begin with a single dot, since these could very well be temporary files such as lock files, swap files, etc., but it should consider importing non-data files and folders with more than a single dot, since it would be very rare for a temporary file to begin with two or more dots.

That'd be great but honestly it might just be easier to strip the dots from the artist/album folder names instead. I'd actually be content with MC replacing the three dots with two underscores, since underscores have no issues on Linux.

MrC · « **Reply #5 on:** January 21, 2014, 05:56:45 pm »

MC can't/shouldn't strip the dots until the files are imported... but the files are not imported because of the dots.

It would be considered bad form for MC to rename files not-yet-imported w/out user permission.

Awesome Donkey · « **Reply #6 on:** January 21, 2014, 06:01:31 pm »

Quote from: MrC on January 21, 2014, 05:56:45 pm

MC can't/shouldn't strip the dots until the files are imported... but the files are not imported because of the dots.

I meant from the Windows side when running Rename, Move, & Copy Files to organize the library. As far as I can tell, you can't customize the feature to either remove or substitute specific characters like the three dots. That's why the idea of having a checkbox or something in that dialog for UNIX/Linux file system support (if you're using other OSes) came to mind. But, it's probably more simple to either support hidden files on Linux/Mac or strip the dots/change to underscores at the beginning of folder names when using Rename, Move, & Copy Files.

MrC · « **Reply #7 on:** January 21, 2014, 06:51:56 pm »

In the Rename tool, in the Filename rule, try any of these:

replace(filename(,0), ., _)
if(regex(filename(,0), /#^\.*(.*)$#/),_[R1],filename(,0))

or use the Find & Replace to change . to _.

Awesome Donkey · « **Reply #8 on:** January 21, 2014, 07:06:38 pm »

But won't that change all periods to underscores? Can't I specify multiple dots (e.g. ...) to become a single or double underscore? Here's my current directories filename rule under rename...

[Album Artist]\[Album]

[Album] is the one that'll need customized to display underscores instead of three dots - artists and song titles as-is will display fine.

MrC · « **Reply #9 on:** January 21, 2014, 07:11:47 pm »

That's why I suggested two different rules, to give you options.

The regex() will replace only the initlal dots by a single underscore. If your directory rule is:

[Album Artist]\[Album]

the change it to:

[Album Artist]\if(regex([Album], /#^\.*(.*)$#/), _[R1], [Album])

Awesome Donkey · « **Reply #10 on:** January 21, 2014, 07:14:01 pm »

Hmmm, just input that rule in, and for the output preview it seems to want to rename all albums with an underscore in the front, instead of just albums with dots in front.

6233638 · « **Reply #11 on:** January 21, 2014, 08:31:07 pm »

Quote from: Awesome Donkey on January 21, 2014, 07:06:38 pm

Can't I specify multiple dots (e.g. ...) to become a single or double underscore?

You should use the ellipsis character.
…

Awesome Donkey · « **Reply #12 on:** January 21, 2014, 08:40:56 pm »

Okay, that's clever! Indeed, that works fine - all albums show up correctly. However, MC for Linux displays the ellipsis character as two dots instead of three.

MrC · « **Reply #13 on:** January 21, 2014, 10:30:16 pm »

Quote from: Awesome Donkey on January 21, 2014, 07:14:01 pm

Hmmm, just input that rule in, and for the output preview it seems to want to rename all albums with an underscore in the front, instead of just albums with dots in front.

Sorry, I *'d when I should have +'d in the new case. Use this:

[Album Artist]\if(regex([Album], /#^\.+(.*)$#/), _[R1], [Album])

Awesome Donkey · « **Reply #14 on:** January 21, 2014, 11:47:53 pm »

Getting closer! However, it's removing the ... at the end of album names, e.g. The Battle Rages On...

It should replace the trailing ... with an underscore too!

MrC · « **Reply #15 on:** January 22, 2014, 12:01:21 am »

I'm unable to create a folder name with ... at the end in Windows. How are you doing that?

The expression doesn't touch any Album name with ... at the end; Album gets passed unmodified.

Awesome Donkey · « **Reply #16 on:** January 22, 2014, 12:02:53 am »

MC somehow did it, which actually caused a problem when running the rename routine. I've fixed it though through Linux (removed the 'bad' folders). All is well (until when/if MC supports hidden file/folders on UNIX/Linux).

Thanks a lot!

My entire library works on Linux now.

MrC · « **Reply #17 on:** January 22, 2014, 12:04:48 am »

I tied to create them with MC too - it will not create these.

Awesome Donkey · « **Reply #18 on:** January 22, 2014, 12:14:18 am »

I believe it happened when I was using find and replace to replace the ellipsis … character with ... and it was throwing errors during the rename routine. Somehow empty folders were created and left behind that ended with ... that I couldn't delete in Windows. Fortunately I knew what the issue was and how to rectify it through Linux.

MrC · « **Reply #19 on:** January 22, 2014, 12:17:47 am »

That's OK, I was able to create them from within Cygwin.

Try this:

[Album Artist]\regex([Album], /#^(\.*)(.*?)(\.*)$#/, -1)replace([R1],.,_)[R2]replace([R3],.,_)

Its a one for one replacement of . with underscore, only at the beginning or at the end.

Awesome Donkey · « **Reply #20 on:** January 22, 2014, 12:21:57 am »

Perfect!

Thanks!

bob · « **Reply #21 on:** February 05, 2014, 07:54:00 pm »

I just discovered a weird one. With the files on a linux virtualbox share importing into my virtualbox windows 7 MC guest, MC skipped a track that had double quotes in the filename. When I replaced the double quotes with underscores it worked fine.

MrC · « **Reply #22 on:** February 05, 2014, 09:44:09 pm »

Niggles.

I repeat myself from above: "MC should at least issue warnings and an explanation about why these files not being imported."

bob · « **Reply #23 on:** February 06, 2014, 03:11:12 pm »

Quote from: MrC on February 05, 2014, 09:44:09 pm

Niggles.

I repeat myself from above: "MC should at least issue warnings and an explanation about why these files not being imported."

I agree, I'm just noting the problems for now.
I ran into another, my linux MC will import files with : in them. When I copy them to a windows filesystem, explorer thinks the : is a part of a drive letter and hacks the filename into a 8+3 hash. Not cool.

INTERACT FORUM

Author Topic: Library folder limitations between operating systems (Read 13445 times)