File/Directory Not Found Error -1101

[wwhigginsjr]

Getting LOTS of these errors during COPY phase of backup on JUST ONE CLIENT and IN ONE DIRECTORY on that one client.

 

The file names that error are too long to post here, but error message looks like this:

 

*File "/Volumes/Server Disk/Users/test1/Library/Caches/Metadata/Safari/History/http:%2F%2Fwww.google.com%2F ... snowbow&zoom=": can't read, error -1101 ( file/directory not found)

 

These error messages repeat for multiple files, all within the /Volumes/Server Disk/Users/test1/Library/Caches/Metadata/Safari/History/ directory.

 

Recycling the backup does not cure the problem.

 

Clearing Safari's history does not cure the problem.

 

No user is active during the backup (which begins at 2:00 AM).

 

Other users have similar files in their own (analogous) directory, but there are no problems/errors with their backups.

 

Any thoughts/leads?

[CallMeDave]

The file names that error are too long to post here

 

Really? Or are you just reporting that the name is longer then you think is appropriate to post?

 

but error message looks like this:

 

*File "/Volumes/Server Disk/Users/test1/Library/Caches/Metadata/Safari/History/http:%2F%2Fwww.google.com%2F ... snowbow&zoom=": can't read, error -1101 ( file/directory not found)

 

Recycling the backup does not cure the problem.

 

Clearing Safari's history does not cure the problem.

So, do those files actually exist in that folder?

 

Have you tried simply trashing the contents of that cache folder?

 

Dave

[Daniels]

Have you tried skipping cache folders and seeing if that resolves the issue?

[wwhigginsjr]

CallMeDave-

 

Thanks for your reply.

 

Really? Or are you just reporting that the name is longer then you think is appropriate to post?

 

Longer than I think is appropriate (both in length of path/ filename as well as in number of entries).

 

So, do those files actually exist in that folder?

 

Have you tried simply trashing the contents of that cache folder?

 

Those files do NOT exist (so Retrospect is correct in saying it can't read them and/or file not found). What I'm wondering is why Retrospect THINKS these files should be there. The error occurs during the COPY phase of a Retrospect backup (not the COMPARE phase), and occurs on the first normal backup following a RECYCLE backup (i.e., the files in question are not in Retrospect's list of previously backed up files).

 

I did trash the cache file using Terminal:

 

sudo rm -dr /Volumes/Server\ Disk/Users/test1/Library/Caches/Metadata/Safari/History

 

Then I ran a recycle backup with no significant errors.

 

Then I launched Safari once (did not surf, stayed at Apple home page), and quit. To my surprise, the folder at /Volumes/Server Disk/Users/test1/Library/Caches/Metadata/Safari/History was recreated and populated with a huge number of files after just one launch. Files in that history cache appear to be the same ones as were previously deleted using Terminal. Safari must have created these from some other history or cache stored elsewhere.

 

Browser behavior got really funky after that. Spinning Color Wheel of Death. Reset Safari (except cookies), and browser works better now.

 

Think I'll do another recycle backup, reset Safari, run a normal backup, and see if the errors return. Will report back.

Edited January 21, 2011 by Guest

[wwhigginsjr]

Daniels-

 

Thanks for your reply.

 

Have you tried skipping cache folders and seeing if that resolves the issue?

 

I'm pretty sure that excluding/skipping the problematic cache folder from Retrospects backup would "solve" the problem.

 

BUT, I'm curious as to why this error occurs for (just) this user. Other users and/or Mac Retrospect clients have analogous files backed up by Retrospect without generating errors.

 

Maybe reseting Safari will cure this issue...

[Maser]

Retrospect has three phases (if you use the default settings)

 

1) The "Scanning/Matching" phase

 

2) The actual "backup" phase

 

3) The "verification" phase.

 

 

If the files were there in phase 1, but not in phase 2 (or phase 3) -- you'll get those "files not found" error messages. That's normal behavior (but, admittedly probably not as clear in the log...)

 

 

[wwhigginsjr]

Some clues as to what's going on, but first the process:

 

1) RESET Safari.

2) Performed a Recycle backup in Retrospect. No significant errors.

3) Did NOT open Safari. Performed Normal backup in Retrospect. No errors.

4) Launched Safari, browsed to a couple of websites, then quit Safari.

5) Performed Normal backup in Retrospect. ERRORS RETURN. Retrospects says can't read, error -1101 ( file/directory not found) return on two files in that same /Volumes/Server Disk/Users/test1/Library/Caches/Metadata/Safari/History/ directory.

 

 

There were two files/two errors. In the Finder, I looked for the two files that Retrospect reported errors on. Found them. They have EXTREMELY LONG file names. Here's the clue: Retrospect error message lists the files, but the names are TRUNCATED by a few characters!

 

APOLOGIES, but I'm not able to make my post read properly. Every time I type "&-a-m-p-;" WITHOUT THE HYPHENS the forum "engine" translates it to a single "&" character. So I am forced to type WITH the hyphens...and you are supposed to read WITHOUT the hyphens.

 

In one error message, the final characters in the Finder filename read:

 

...fsmregister&-a-m-p-;afterw

but Retrospect truncates this to:

 

...fsmregister&after

 

Note the missing "w" (at the end), as well as the truncation of some kind of ampersand code (&-a-m-p- in Finder to "&" in Retrospect.

 

 

In the other error message, the final characters in the Finder filename read:

 

...2526sType%253DF&afterward

 

but Retrospect truncates this to:

 

...2526sType%253DF&afterwar

 

Note missing "d"

 

 

Microsoft Word says the two Finder strings are both 255 characters long. It says the two path names in the Retrospect error strings are 314 characters long (first/top file error above) and 326 characters long (second/bottom file error above). The Retrospect path names are longer (314 vs. 255; and 326 vs. 255) because Retrospect includes the full path (/Volumes/Server Disk/Users/test1/Library/Caches/Metadata/Safari/History/...) in the error string. The directory path accounts for 72 characters. If you strip out the directory path from the Retrospect error string to get to just the file name, the first/top file error is 242 characters long (vs. Finder length of 255 characters) and the second/bottom one is 254 characters long (vs. Finder length of 255 characters).

 

Again, Retrospect is truncating the file names.

 

The &-a-m-p-; truncation amounts to 4 characters per occurrence. That string occurred 3 times in the Finder filename of the first/top file error, accounting for 12 of the 13 missing characters. The 13th/final missing character is the "w".

 

In the second/bottom file error, the difference in the filename length--254 (Retrospect) vs. 255 (Finder)--is (solely) attributable to the missing "d".

 

Seems (to me anyway) like a bug. The filename translation between Finder and Retrospect ought to be "true" (i.e., what goes in is the same as what comes out).

 

Also note that ALL the other files in this directory have Safari icons (white page with blue compass). The two files that Retrospect error-ed on have blank icons (white page, nothing else).

 

Any thoughts?

Edited January 23, 2011 by Guest

[Maser]

Because I'm curious...

 

Where is the truncation? Only in the log?

 

What if you move the file in question (or a copy of the file) to the root level of the drive (or a new subfolder on the root level?) if you do another backup?

 

Do you get a "file not found" and the name of copy the file still get truncated (meaning is the truncation a function of the path length -- which would clearly be a bug -- but maybe only in the log...)

 

If so...

 

Does a "Preview" of the file in question have any truncation?

 

Or if you *can* backup the file, does it restore properly?

[CallMeDave]

Then I launched Safari once (did not surf, stayed at Apple home page), and quit. To my surprise, the folder at /Volumes/Server Disk/Users/test1/Library/Caches/Metadata/Safari/History was recreated and populated with a huge number of files after just one launch. Files in that history cache appear to be the same ones as were previously deleted using Terminal. Safari must have created these from some other history or cache stored elsewhere.

 

Browser behavior got really funky after that.

 

So it seems apparent that there is something funky going on with your system or user account that is affecting Retrospect, not the other way around.

 

You might want to do a Safe Reboot, or run OnyX, and see if you can fix the funk before asking Retrospect to behave as if everything is all right.

 

 

Dave

[Maser]

I just tried this -- I removed my ~/Library/Caches/Metadata/Safari/History" directory (which had about 6-10 files in it), then launched Safari and that directory was *not* recreated.

 

Not sure what that means, but I'd pile on Dave's request to run OnyX (or at least Snow Leopard Cache Cleaner) and see if that makes any difference.

 

 

[wwhigginsjr]

Thanks for the replies. Still getting to your tests/suggestions, but have some more data points...

 

I ran a Normal Retrospect backup overnight after doing a minimal amount of browsing yesterday in Safari in this user account. 8 new error messages (similar to those already identified) were logged in Retrospect (in addition to the two previously dissected).

 

• 1) Each and every of the 8 new file not found errors happens on a Finder filename that is exactly 255 characters in length.
  2) Each and every of the 8 new file not found errors happens on a Finder file that is missing its Safari icon.
  3) Assuming the translation from "&-a-m-p-;" (in the Finder) to "&" (in Retrospect log) is "normal," each of the 8 new file not found errors is missing the final character in the filename that Retrospect reports in its error message.
  

 

Not sure we should jump to the conclusion that the user account is funky (yet). Consider the actual troubleshooting steps:

 

• 
  1) Received suggestion to trash contents of cache folder where errors were occuring.
  2) Did.
  3) Browser behavior got funky. Not system behavior, or user behavior, but browser behavior.
  4) Reset Safari.
  5) Everything (other than original problem) back to normal.
  

More straightforward conclusion is that trashing the folder via Terminal made the browser behavior funky. Resetting Safari appears to be the "correct" way to do this sort of thing.

 

Back with more once I can conduct your tests...

[wwhigginsjr]

One other point on the file not found files:

 

None have a suffix (i.e., ".webhistory). All other files (that do not cause error messages in Retrospect) in that folder have the suffix ".webhistory"

 

I am guessing that this is why the Safari icon does not appear with the files when looked at in Finder.

 

Also, in other user accounts, I can't seem to find ANY cache files (in this location) that have filenames that are 255 characters long. All are shorter. Is this a Mac OS X file naming convention (i.e., Mac OS X can accommodate filenames up to 255 characters in length)?

Edited January 24, 2011 by Guest

[wwhigginsjr]

Some answers to Maser's questions:

 

What if you move the file in question (or a copy of the file) to the root level of the drive (or a new subfolder on the root level?) if you do another backup?

 

I was able to copy one of the original problem files to two other folders (using Finder): one a sub directory on the root machine where the Retrospect engine runs; the other a shared folder. Copy (in Finder) went normally in both cases. When I ran a normal backup in Retrospect, a new error message was generated for each of the two new occurrences of this file. The error message in the Retrospect log reads exactly like the original I reported. There's the &-a-m-p-; translation and a missing final character.

 

When I renamed the two files that I just copied to "shortfile.webhistory", the Finder icon that was previously missing reappeared. There were NO BACKUP ERRORS reported for these renamed files when I ran a normal backup in Retrospect.

 

Does a "Preview" of the file in question have any truncation?

 

Not sure what you mean. Finder Preview? The name as listed in the Finder column matches the name as listed in the Finder Preview column (one column to the right). Perhaps you're referring to some "preview" function in Retrospect. If so, please clarify/point to.

 

 

Or if you *can* backup the file, does it restore properly?

 

As above, I was able to backup the files using Retrospect once they were renamed to "shortfile.webhistory". They restored properly (as far as I can tell). The original files (having a 255 character-length filename) never got backed up, so cannot be restored.

 

 

I'm no expert, but looks to me like two errors:

 

• 
  1) Safari makes an error in trying to save a cache file that is longer than the filesystem can handle.
  2) Retrospect makes an error in not backing up/truncating the final character of a file whose filename is 255 characters in length.
  

 

 

Other thoughts?

[CallMeDave]

Is this a Mac OS X file naming convention (i.e., Mac OS X can accommodate filenames up to 255 characters in length)?

 

Yes.

 

See Table 1

 

 

Retrospect makes an error in not backing up/truncating the final character of a file whose filename is 255 characters in length.

Since the file(s) in question appear to be dynamically (and quite possibly rapidly) created and/or modified, it's unknown what Retrospect is actually choking on or being choked by.

 

Better tests would remove Safari's cache creation from the equation. Create files with long names, with long paths, with and without extensions, and see how Retrospect handles them.

[Lennart_T]

Maybe there's something wrong with the disk directory?

 

Try repairing the drive using "fsck" in single user mode, or boot with the system DVD and run Disk Utility, or install AppleJack and let it run all steps.

[Maser]

I tried something similar and the Finder would not allow me to create a file with a name larger than 255 characters (basically 251 characters ending with ".txt"

 

However, for the file I created that is 255 characters, I see the same problem -- the log lists the problem file as being "<251characters>.tx". If I remove one letter from the file name -- then the file backs up.

 

 

I'll see if I can get this added as a bug report.

 

The better question is why does an application need a 255 character file name?

 

[wwhigginsjr]

Thanks for the replies.

 

...I'd pile on Dave's request to run OnyX (or at least Snow Leopard Cache Cleaner) and see if that makes any difference.

 

Downloaded OnyX, and used it to reset a bunch of things in Safari (OnyX tab labeled "Clean" and sub-tab labeled "Internet"). Not sure if that's all you intended me to do. If there's more, please instruct.

 

Following cleaning with OnyX, I did a minor amount of browsing, and noted that Safari generated some cache files in that same directory (some with excessively long file names which were missing the .webhistory suffix and missing their Finder icon/thumbnail). Retrospect ran its normal backup overnight, and encountered/reported errors on those same cache files with excessively long file names.

 

 

Better tests would remove Safari's cache creation from the equation. Create files with long names, with long paths, with and without extensions, and see how Retrospect handles them.

 

I like your thinking here. I did duplicate one file (an Excel file), and renamed it with a 255 character length file name. Then ran normal Retrospect backup. Result: file/directory not found error in Retrospect.

 

Deleted one character from that filename, re-ran the Retrospect normal backup, and did NOT get a Retrospect error on that file. Conclusion is that filenames that are 254 characters long do get backed up by Retrospect, whereas filenames that are 255 characters long do not. Definitely a bug.

 

The better question is why does an application need a 255 character file name?

 

AGREED! But please remember that 'tis not I that created such long filenames! It was Safari. Just as important, Safari is ATTEMPTING to create cache files whose names are (sometimes) longer than allowed by the Mac OS X file system (limit is 255 characters). Several of my icon-less cache files obviously got truncated by Finder: I got a couple that end ".webh" (but many more that end without any suffix, meaning they got truncated/reached their 255 character limit before getting to the ".webhistory" part of the filename.

 

Anyone know how to report this to the great and powerful Apple?

[Maser]

I reported this as a bug and it's now in their bug-tracking system (which means engineering can reproduce it...)

 

 

But, as a workaround, either ignore the problem or use the "all files except cache files" rule (which is what I do...)

 

 

As for how to report bugs to Apple: http://bugreporter.apple.com

 

 

It's free to submit bugs to Apple -- you just have to sign up to do so. If you can reproduce the problem ("Safari creating files longer than 255 characters"), that'll make it easier for the developers to fix.

 

 

 

Is there a specific web site you visit that's generating the greater-than-255-character file names? I checked my history folder and nothing in there comes close...

[wwhigginsjr]

Maser, thanks for your help, and thanks for handling the Retrospect bug report.

 

I submitted a bug report to Apple using the link you provided.

 

Is there a specific web site you visit that's generating the greater-than-255-character file names? I checked my history folder and nothing in there comes close...

 

I believe the Safari error may happen only when the user has a Network Home Directory. I did not find any truncated files in the ~/Library/Caches/Metadata/Safari/History directory when the user had an (ordinary) local Home directory.

 

That said, with a Network User (having a Network Home Directory), I had lots of errors from multiple web sites including Google, eBay, and FedEx. Here's one process that reliably crated a truncated history cache file:

 

• 
  1) Launch Safari.
  2) Perform Google Search using following terms: sferra bros giorgio
  3) Select link:

http://www.sportslinkup.com/shop/0-Sferra-king-7.html
4) Use Safari "Find" utility (Command-F) and search for: giorgio
5) Click on the link labeled Buy Now>>> at the item labeled "NIP Sferra Giorgio Sham-King-Slate​-2 Available"

 

[Maser]

Hmm...

 

When I do your steps, I only get these:

 

 

-rw-r--r-- 1 maser admin 8787 Jan 26 13:47 http:%2F%2Fwww.google.com%2Fsearch?client=safari&rls=en&q=sferra+bros+giorgio&ie=UTF-8&oe=UTF-8.webhistory

 

-rw-r--r-- 1 maser admin 15428 Jan 26 13:48 http:%2F%2Fwww.sportslinkup.com%2Fshop%2F0-Sferra-king-7.html.webhistory

 

-rw-r--r-- 1 maser admin 303 Jan 26 13:48 http:%2F%2Fcgi.ebay.com%2FNIP-Sferra-Giorgio-Sham-King-Slate-2-Available-%2F360333675529?pt=US_Pillow_Shams&hash=item53e58f8c09&x=28&y=6.webhistory

 

 

 

Nothing was truncated on my end in my "history" folder (but, as you say, I don't have a network home directory...)

 

What do you see and what's the path name of the enclosing folder?

[wwhigginsjr]

What do you see and what's the path name of the enclosing folder?

 

 

http/%2F%2Frover.ebay.com%2Frover%2F1%2F711-53200-19255-0%2F1?campid=5335807129&toolid=10001&mpre=http%253A%252F%252Fcgi.ebay.com%252FNIP-Sferra-Giorgio-Sham-King-Slate-2-Available-%252F360333675529%253Fpt%253DUS_Pillow_Shams%2526hash%253Ditem53e58f8c09.w

 

The enclosing folder is:

 

~/Library/Caches/Metadata/Safari/History

 

Theres probably an afp://servername.domainname etc in front of that path, but I'm a bit rusty in specifying it out properly (and don't want to mislead).

 

In Terminal, the path is:

 

/Network/Servers/servername.domainname/Volumes/Server Disk/Users/test1/Library/Caches/...

[Maser]

And you are only getting this truncation when you use an account that runs from a network home directory?

 

If so, make sure you indicate that clearly in your bug report to Apple (I have no way of testing that here...)