So, I'm not sure if this is normal behavior or not, but the orange ball next to one of my user shares will not turn green.

The user share is my media share.

I've got Plex / SAB running on a Cache drive, and it is set to download all new content to my media share.

The share has 'use cache drive' set to yes.

 

I thought that it would turn green once I invoke the mover, but it is still orange.

 

Is this normal, or should it be turning green after I invoke the mover?

as long as it says "use cache yes" and not "use cache only" it should turn green after the Mover has finished transferring content from cache to the share unless the content is stuck in one of the default Mover exception folders...ie folders set to cache only and folders that have a "." at the beginning of folder name

Thanks nacat,

 

The Media Share is set to "use cache yes"...However, the Application share where I installed the apps (Plex and SAB) was set to "use cache only".

I know that the Application share will always be orange, but it sounds like the Media Share should be green now...especially after I invoke the mover.

 

unless the content is stuck in one of the default Mover exception folders...ie folders set to cache only and folders that have a "." at the beginning of folder name

 

I don't have any folders set like that....and I also looked in the cache folder under 'Media' and it was empty...which I believe means the mover worked...

 

Any ideas?

 

unless the content is stuck in one of the default Mover exception folders...ie folders set to cache only and folders that have a "." at the beginning of folder name

 

I don't have any folders set like that....and I also looked in the cache folder under 'Media' and it was empty...which I believe means the mover worked...

 

Any ideas?

How did you look in the cache folder? Folders that have a "." at the beginning of the folder name are normally hidden folders.

From telnet or console, do you see anything if you do

ls -al /mnt/cache/Media

?

This was the result:

 

total 0

drwxrwxrwx 3 nobody users  72 2013-12-18 11:57 ./

drwxrwxrwx 6 nobody users 200 2013-12-17 19:22 ../

drwxr-xr-x 2 root  root  192 2013-12-17 20:36 .AppleDB/

This was the result:

 

total 0

drwxrwxrwx 3 nobody users  72 2013-12-18 11:57 ./

drwxrwxrwx 6 nobody users 200 2013-12-17 19:22 ../

drwxr-xr-x 2 root  root  192 2013-12-17 20:36 .AppleDB/

./ just represents the folder itself

../ represents the folder above (its parent)

.AppleDB/ is the culprit. I don't do Apple so I don't know why it's there or what you should do about it. I'm sure there are other posts about this if you search.

I'll look into it. Thanks for the help.

I'm guessing that file is created by Plex. Tr manually moving it to the array and see if it works after that. I suspect Plex will just keep updating that file so if you put it on the array it will stay there and quit causing a problem.

 

So I looked at the cache folder .appledb and it contained the following files:

__db.001

__db.002

__db.003

__db.004

__db.005

__db.006

 

I then went into the Media share, and the .appledb folder was there as well, with all of the same exact files (filesizes as well)...but it had a few more files...

I didn't copy the folder over.  Does it make sense that this file is still the culprit if my media share has those files as well?

 

The .00x files are parts of a segmented file. If the segments have been successfully combined into a final file, then the segments can be deleted.

---

In general, Apple uses these 'hidden dot files' for housekeeping.  (the '.' makes them invisible by default on OS X and Windows)

 

 

On your Mac you see them in a couple of places...they hold the Finder information such as a file's location on the desktop, or its 'tags'. This sort of info shouldn't actually be stored in the file.  (turn on invisible files in finder, and you'll see them all over the place)

 

 

They also are used when files are newly created and are still 'open' for writing.

 

For example, to copy file 'X.txt' from DiskA to DiskB, Apple might create a file called '.X.txt' on DiskB.

As data is copied, it goes to DiskB ".X.txt". When successful, the file is renamed and the '.' is removed, making it visible.

 

 

Torrents and downloads often 'restart' their downloads and creating a new file. If the original download terminated abnormally, the '.'dot file is sometimes left behind by the torrent or download software.  This can lead to 'extra' dot files that are no longer tied to an active finder operation, and consequently aren't cleaned up properly.

 

 

*IF* the final file is complete and visible in your Finder, then any corresponding 'dot' file or folder can be safely deleted.

---

 

• Its also possible that the MOVER is not appropriately deleting the files with the names beginning with "__"...that's a pretty uncommon first character.
  
• Its also possible that your 'join' program (whatever you use to 'unarchive' or reassemble all the '.00x' files into a whole) is tripped up by the beginning "__" and doesn't properly delete them after rejoining.  (In your joining software, there's probably a Preference setting to DELETE segments after joining. That should be ON. Still, those beginning characters may be a problem.)
  

 

 

Thanks Dale,

 

Quick question - how can I verify that the file is complete?

It is a hidden folder, it only showed up when I enabled hidden folder/file viewing in terminal.

 

I tried to copy the file, and then delete it (via finder), but it wouldn't allow me to do either...

I'm sure I could delete the file through telnet/console, but I don't want to do something that could potentially screw anything up..

Of course the files exist in the media share as well. The share includes what is on the cache drive.

 

If those files are created by an Apple product then you can just remove them. But, they'll get recreated and be put on the cache again if they were some kind of data file holding information about contents of the server.