MAC FMServer v12 Error 685, only affects Externally Stored Container files

[LelandLong]

Mac OS X Server v10.6.8

FileMaker Server 12.0.1.178

During a daily scheduled backup in which it's set to keep a maximum of 14 backups, once there are 14 folders as expected I am receiving error messages stating:

FMServer Error 685 Error occurred while deleting backup folder...

When I look at the folder(s) in question it has successfully deleted all the database copies, only leaving the externally stored container files. All of them. And their folders.

I looked at the permissions for each folder and they were all identical; all having fmserver/fmsadmin with Read & Write priv's.

Thoughts, suggestions ?!

[Oxyturbo]

Same problem here, did you solve it?

Silvio

[Aristide]

Hello,

i have exactly the same problem here...

it seems to be a permission problem but i can't find the wrong one...

Someone found the solution ?

Thank you

Aristide

[Vaughan]

FMS 12 uses hard-linking to save space by not duplicating files that have not changed.

If a file was backed up on, say, 1/1/2012 and not changed since then then all other backups are hard-linked to this file. The original file nor the containing folder cannot ever be deleted.

[brendandaly]

FMS 12 uses hard-linking to save space by not duplicating files that have not changed.

If a file was backed up on, say, 1/1/2012 and not changed since then then all other backups are hard-linked to this file. The original file nor the containing folder cannot ever be deleted.

I can see what you are saying there so does that mean we just have to wait until FileMaker solve this problem? Is it solvable? Should be submit a bug report?

[brendandaly]

I did some further research and the Hard Linking only occurs within the backup folders (I did this looking in terminal and looking at the inode numbers and counts) and from what I understand the original files should therefore be able to be deleted by the backup schedule.

[Aristide]

Same problem with the 12.0.2.232 upgrade...

[fmhappyguy]

Same /$&$"! error every night. "some files or folders could not be deleted"

I bet I'll have to make a terminal script to do a rm -r Server/Data/Backups/*.* script

Frustrating. I'm not happy with Server12.

[Aristide]

Same problem with the 12.0.3 upgrade...

 

pffff...

[Justin Close]

I am also having this problem with FMSA 12.03.327.

 

Our problem appears to have been a recent change, though; we haven't been getting this error the entire time we have been on 12, just in the past week or two, or at least as far back as 2/03 which is as far as the logs go...

 

Also, we appear to have some odd behavior:  the server kicks out two error messages for two different directories.  E.g. it complains that it can't delete "filemac:/Server.../Hourly_2013-02-17_0930", and in a separate message, complains about "filemac:/Server.../Hourly_2013-02-17_1030".  In the next hour it will complain about directories "...Hourly_2013-02-17_1030" and "Hourly_2013-02-17_1130".  So it keeps rolling forward.  The REALLY odd part, perhaps, is that the earlier directory it complained about in the first pair of messages ( "Hourly_2013-02-17_0930" in this example) is GONE after it complains about the next two directories.  And if you look at the files in the directories, it appears that it is in fact deleting some of the files at each stage.

 

I went through and did a 'chmod' on these directories to see if that would help, but it doesn't appear to have fixed anything.  I ran:  "sudo chmod -LR 775 Hourly_2013-02-17_1030/" and also "sudo chmod -LR 775 Hourly_2013-02-17_1130/" before this last backup run, and those are the same two directories that it then complained it couldn't delete.  Owner = fmserver, Group = fmsadmin.  I attached a screenshot with the permissions BEFORE running the commands.)

 

 

[HALBURN]

Same problem here!

Version: 12.0.3.327
 

[John May - Point In Space]

We've spoken with FileMaker about this and were told this bug is specifically related to the number of files in the parent directory.  Apparently, the number of files in each directory needs to be under about 100, otherwise this problem occurs.  You can either manually limit things this way, or set up a cron'd shell script or AppleScript to clear any older directories from the backup path (we did the latter here).  I would assume FileMaker will eventually squash this bug, since they're aware of it.

 

- John

[JerrySalem]

This has been discussed on some of the other boards, and it seems the best solution is to change the path for storage of the remote containers.

For example, if you have a table called people, with a primary key field called _kp_PersonID, and a container field called photo.

instead of storing the images either in the base folder, or in a sub folder like "/Images/"

save the images to a subdirectory based on the primary key; "/Images/" & _kp_PersonID & "/"

This way you get a folder for each record.

 

Jerry

[HALBURN]

It seems like this is the type of bug that they would have a team working on around the clock to fix, yet somehow I don't think anyone at FileMaker is even looking into it. We are up to version 12v3 and none of the bugs that I have reported have been fixed and it does not seem any faster to me than the original release.

[Justin Close]

Darn it all, but I must have not had subscription activated for this thread when I replied back in Feb.  I have been silently suffering with this error message since that time; until recently anyway.  I was at Pause on Error this past week and talked about my problems with a very helpful Richard Carlton and Matt Navarre.  (Just double checked - I AM following this topic.  I don't recall getting updates about responses!)

They gave me the right answer, the same as posted here by John May:  the problem is due to the number of files in a directory.  (Curiously - considering it is a Unix based filesystem - the subdirectories don't count as 'files' in this case.)

I implemented a fix and came back here to report on it…but John had already given the answer, and suggestions on how to work around the issue (i.e. break down the storage into more and more subdirectories, such as using one sub-directory for each record by including the RecordID in the path for the container, as Jerry Salem has noted above).

I found that we had a directory with 750+ files in it.  This had been caused when one of our external storage containers had the path commented out; the text was still there but it was just commented out!  Not sure how that happened.  When I uncommented the path, and waited for old directories to get flushed out, the errors went away!  So much email-inbox-not-flooded-happiness! 

Thanks John, Richard, and Matt!

--  J

[fishtech]

the best solution is to change the path for storage of the remote containers.

 

 

 

Thanks, Jerry.

 

This worked best for me. I prefer this approach to having to run scripts.

 

My solution is a timecard system, taking many photos of the same person over time when they punch in or punch out for work.

 

In the field definition I chose OPen Storeage with the calc:

 

 

Let (
[
d=GetAsDate(dPunchInDate);
dd= Year(d) & Month(d) & Day(d)
];


"ImageIn/" & fkPersonID &"/" & dd &"/"
)

There should never be more than 4 files stored in one folder.

 

Thanks,

 

ft.