This question is very similar to this thread, but has one major difference:  there is only one file in the subdirectory in question.

 

Overall description:  I started getting 685 errors again this weekend: 

Error    685    server.addr.ess    Error occurred while deleting backup folder 
"volume:path/to/file", some files or folders could not be deleted. (-1)

I thought that I was having the same problem as I had had previously:  something in the path calculation for the external container field had gotten messed up (e.g. field renamed) and that all the files were being dumped into a parent directory or something. 

 

But that was NOT the case.  In looking at the directory that it said it couldn't delete there was only one directory/subdirectory tree left in that path, with only 1 file in that subdirectory.  I went to that directory in a more recent backup copy (i.e. one that it hadn't tried to delete yet), and there was only 1 file there, too.

 

I did a test where I deleted this file and subdirectory from a backup BEFORE it tried to remove it, and I received no error message when that one's turn came up.  I did this a few other times to verify.  So deleting this one file and one subdirectory prevented the error from cropping up.

 

I looked at the permissions on the file and they appeared to match what all the other files in other similar subdirectories were.

 

Anyone have any ideas?

 

Thanks,

--  J

Did a slightly different test:  just deleted the file from the subdirectory.  In that case, I still got an error message when the server attempted to delete that backup.

Me again, with the same problem as before. 

 

After some sage advice it was noted that my original problem appeared to be caused by there being too many files in a single sub-directory.  Something had gotten messed up in the external container path definition and so it wasn't creating subdirectories for each record.  With all those files dropping into one directory, FMS was having trouble handling them (apparently a bug).  When that was corrected , the problem has gone away for a few months but has now returned in earnest.  And this file/record has NOT changed during that time.  (This is an older record; they don't tend to get updated once they are 'done'.)

 

But this time the subdirectories ARE correctly in place.  And again, it is the same subdir/file combination that is being left over as in the first occurrence of this problem.  Sometimes this remaining file will get cleaned up with the next backup process runs, but other times it won't, and it various backup directories will just start to pile up unless I manually delete them.

 

I have done many tests in a variety of situations, but I don't seem to have been able to narrow it down.  In some situations a single variable seems to be the cause, but moving that variable around leads to a condition where the backup directory gets deleted without troubles.

 

It appears the FMS has troubles if the directory structure has exactly 2310 subdirectories in it (in a single/particular folder).  But that isn't the only problem; as noted it appears to be the same subdir/file combination that is being left behind, and that can cause the server to continually fail to delete a backup directory even if it is the only file in the directory (i.e. as is the case after it tries to delete it the first time around).  But I have run tests on more/less subdirs in this one folder and it has at various times passed/failed those tests too. 

 

Removing the file in question typically seems to help, but I can't seem to get it to CONSISTENTLY fail with the file in some place (same or different directories as it would normally show up, more/less directories, etc).  I have rebuilt the file in a few different ways, but that doesn't seem to affect things:  it is an Excel file, so I copied and pasted the data into a a new file (and then saved that to the directory), pasted the data into a text file, then into Excel file again; pasted the data into a simple plain-text file and then saved THAT to the folder structure (and the record).  I have done tests with moving the file into other directories; just leaving the parent directory in place but with no file; putting a copy of the parent directory into other subdirectories instead of in its own directory; etc. 

 

So, that's my story.  I have more testing to do, but if anyone has any advice....

 

--  J