AppleScript "scan for new files" duration and "close & lock" access

First of all, I’m really enjoying EagleFiler 1.5. It’s a wonderful update. Thank you, Michael!

I use ChronoSync to backup my sparsebundle disk image containing my EF library to the cloud. In that process, I created an applescript to close the EF library then unmount the disk image so it’s ready to be sync’d. This brought a couple questions:

  1. Before closing the library, I want EF to “scan for new files” to import new files that Hazel, or some other script, might have added. In my Applescript, I run the following:

tell application "EagleFiler"
	scan for new files document "EFLibrary.eflibrary"
	close document "EFLibrary.eflibrary"
end tell

Though I did not observe a progress bar in the Activity window, EF would throw an error stating “A library operation is in progress. The library cannot be closed while its files are in use. The Activity window shows the operation(s) that are in progress on this library. You can wait for them to finish or click the “x” button(s) to cancel them.” My solution so far has been to add “delay 30.0” between the “scan” and “close” commands. Is there a more intelligent way to tell EF via Applescript to close a library after EF is done scanning for new files?

  1. Sometimes, after closing an EF library (either manually or via Applescript) the disk image won’t unmount. After quitting EF, the disk image will unmount without issue. Is there a way, via Applescript, to confirm a library has released its lock on the file structure so I can safely unmount the disk image? I’ve tackled this in Applescript by adding a try block and asking EF to quit if the disk image unmount command fails.

  2. Perhaps a way to make all of this easier would be to use the new “close & lock” command. Is there a way, without scripting the UI, to access the “close & lock” command via Applescript?

Thanks in advance for your help!

(Early 2008 Mac Pro, 10.6.5, 10GB RAM, EagleFiler 1.5.1)

It looks like the “scan for new files” command correctly waits until the scan is done before returning (so you don’t need to delay 30 seconds) but that it returns a split second before the item has been removed from the Activity window. I’ll see if I can fix this for the next release, but in the meantime a shorter delay should work.

Sounds like there’s a bug here. Can you use “lsof” to determine which files are open while EagleFiler is still running?

Not currently, but that’s on the to-do list.

Disk Image won’t unmount - locked file
Michael, thank you for your assistance.

I’ll see if I can track down the offending file(s) next time it happens.

Results of lsof to determine which file is preventing disk image from ejecting
Hi Michael,

As promised, here are the results of the lsof command I executed (sudo lsof | grep EagleFiler > results.txt) after I attempted to unmount a sparsebundle disk image containing an EagleFiler library which I recently closed using the “Close & Lock” menu command:

EagleFile 1243 eagleuser cwd DIR 14,8 2142 7461593 /Applications/EagleFiler.app/Contents/Resources
EagleFile 1243 eagleuser txt REG 14,8 115984 7461590 /Applications/EagleFiler.app/Contents/MacOS/EagleFiler
EagleFile 1243 eagleuser txt REG 14,8 195600 7461989 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/zlib.so
EagleFile 1243 eagleuser txt REG 14,8 2735812 7461533 /Applications/EagleFiler.app/Contents/Frameworks/Python.framework/Versions/2.5/Python
EagleFile 1243 eagleuser txt REG 14,8 492944 7461972 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/objc/_objc.so
EagleFile 1243 eagleuser txt REG 14,8 69124 7461967 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/itertools.so
EagleFile 1243 eagleuser txt REG 14,8 78264 7461951 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/array.so
EagleFile 1243 eagleuser txt REG 14,8 99476 7461930 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/_File.so
EagleFile 1243 eagleuser txt REG 14,8 367480 7461964 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/Foundation/_Foundation.so
EagleFile 1243 eagleuser txt REG 14,8 66760 7461919 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/_AE.so
EagleFile 1243 eagleuser txt REG 14,8 46224 7461961 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/ExceptionHandling/_ExceptionHandling.so
EagleFile 1243 eagleuser txt REG 14,8 390632 7461950 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/AppKit/_AppKit.so
EagleFile 1243 eagleuser txt REG 14,8 43344 7461958 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/cStringIO.so
EagleFile 1243 eagleuser txt REG 14,8 51816 7461985 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/time.so
EagleFile 1243 eagleuser txt REG 14,8 63648 7461983 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/strop.so
EagleFile 1243 eagleuser txt REG 14,8 52496 7461954 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/collections.so
EagleFile 1243 eagleuser txt REG 14,8 29304 7461947 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/_weakref.so
EagleFile 1243 eagleuser txt REG 14,8 108016 7461944 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/_socket.so
EagleFile 1243 eagleuser txt REG 14,8 43964 7461945 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/_ssl.so
EagleFile 1243 eagleuser txt REG 14,8 158164 7461957 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/cPickle.so
EagleFile 1243 eagleuser txt REG 14,8 61164 7461946 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/_struct.so
EagleFile 1243 eagleuser txt REG 14,8 957740 7461986 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/unicodedata.so
EagleFile 1243 eagleuser txt REG 14,8 33868 7461932 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/_functools.so
EagleFile 1243 eagleuser txt REG 14,8 39076 7461982 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/select.so
EagleFile 1243 eagleuser txt REG 14,8 38048 7461962 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/fcntl.so
EagleFile 1243 eagleuser txt REG 14,8 50640 7461952 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/binascii.so
EagleFile 1243 eagleuser txt REG 14,8 154740 7461959 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/datetime.so
EagleFile 1243 eagleuser txt REG 14,8 38808 7461969 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/math.so
EagleFile 1243 eagleuser txt REG 14,8 38668 7461940 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/_random.so
EagleFile 1243 eagleuser txt REG 14,8 56740 7461988 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/WebKit/_WebKit.so
EagleFile 1243 eagleuser txt REG 14,8 38412 7461933 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/_hashlib.so
EagleFile 1243 eagleuser txt REG 14,8 50104 7461942 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/_sha256.so
EagleFile 1243 eagleuser txt REG 14,8 115640 7461943 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/_sha512.so
EagleFile 1243 eagleuser txt REG 14,8 43512 7461936 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/_locale.so
EagleFile 1243 eagleuser txt REG 14,8 492704 7461575 /Applications/EagleFiler.app/Contents/Frameworks/WashFramework.framework/Versions/A/WashFramework
EagleFile 1243 eagleuser txt REG 14,8 59280 7461973 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/operator.so
EagleFile 1243 eagleuser txt REG 14,8 47580 7461980 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/Quartz/_Quartz.so
EagleFile 1243 eagleuser txt REG 14,8 47348 7461956 /Applications/EagleFiler.app/Contents/Resources/lib/python2.5/lib-dynload/CoreData/_CoreData.so
EagleFile 1243 eagleuser txt REG 14,8 140252 7461554 /Applications/EagleFiler.app/Contents/Frameworks/SkimNotes.framework/Versions/A/SkimNotes
EagleFile 1243 eagleuser txt REG 14,8 1760576 7461525 /Applications/EagleFiler.app/Contents/Frameworks/MJTFoundation.framework/Versions/A/MJTFoundation
EagleFile 1243 eagleuser txt REG 14,8 2080564 7461459 /Applications/EagleFiler.app/Contents/Frameworks/MJTApplication.framework/Versions/A/MJTApplication
EagleFile 1243 eagleuser 5r REG 14,8 749 7461594 /Applications/EagleFiler.app/Contents/Resources/boot.py
EagleFile 1243 eagleuser 6w REG 14,8 2063836 8298963 /Users/eagleuser/Library/Logs/EagleFiler/EagleFiler.log
EagleFile 1243 eagleuser 7u REG 14,8 22528 8111363 /Users/eagleuser/Library/Caches/com.c-command.EagleFiler/Cache.db

Also, I ran “What’s Keeping Me?”, which pulled up the following result (aside from listing the open “bands” on the sparsebundle):

Process Name: EagleFiler
Process ID: 1243
The Open File: /Volumes/EFSparseDisk/EFLibraryFolder/EFLibrary.eflibrary/Indexes/Damaged/Records.efindex

That “Damaged” part of the path has me a touch worried. Quitting EagleFiler allowed the disk image to unmount successfully.

Anyway, I hope this helps. Any ideas for me?

It does not appear that any of these are on the encrypted disk image.

The OS reported an error when EagleFiler tried to open the search index file, so it moved the index into the Damaged folder and built a new index. I would not expect this to happen again, but either way please let me know which files on the disk image are open next time.

This is fixed in EagleFiler 1.5.2.

“What’s Keeping Me” results to see which file is preventing disk image from ejecting
Hi Michael,

First of all, thank you for notifying me about EF 1.5.2. I’ll test it soon.

Secondly, I received the same error as before which prevented my sparsebundle disk image from unmounting. I ran “What’s Keeping Me” and it reported the following:

Process Name: EagleFiler
Process ID: 52036
The Open File: /Volumes/EFSparseDisk/EFLibraryFolder/EFLibrary.eflibrary/Indexes/Damaged/Records-1.efindex

There are now two “damaged” index files. I’ve run the disk image through two disk programs (Disk Utility and Disk Warrior), but they couldn’t find any notable issues. Might you have any recommendations?

Is the disk image stored on an internal or external drive? You could use Drive Genius to do a Scan to check your drive for bad blocks.

Or this may simply be a software problem. I’ve seen cases where Search Kit corrupted its index files when, as far as I could tell, there was nothing wrong with the drive.

Results of disk drive testing utilities
The disk image is stored on the internal boot drive.

I ran Drive Genius a month ago, and then again last week. No bad blocks.

If you have any additional recommendations, I’d be happy to perform additional tests to help narrow down the issue. This isn’t a show-stopper, just worrisome.

Thank you again for your dedication and assistance.

Just to be clear, in order to check for bad blocks you need to use the Scan feature, not the regular Verify/Repair feature.

Disk drive testing utilities

Just to be clear, in order to check for bad blocks you need to use the Scan feature, not the regular Verify/Repair feature.

Understood. No bad blocks.

Here’s what I’ve used:
Disk Utility - General drive check.
Disk Warrior - Check files, repair permissions, and rebuild directory.
Drive Genius - Scan for bad blocks.

I’ll shamefully admit that I even ran ClamX.

Failed to eject disk image again
I used the “close and lock” menu option recently and the disk image failed to eject (EF 1.5.2). This is a second disk image holding a separate EF library than the one before. I ran “What’s Keeping Me” and it reported the following:


Process Name: EagleFiler
Process ID: 7823
The Open File: /Volumes/EagleSparseDisk/EagleLibrary.eflibrary/Contents.db

Quitting EF allowed the disk image to eject.

I’ve seen this a couple times on my Mac and am investigating what might be causing that file to remain open.

Failed to eject disk image due to Contents.db

I’ve seen this a couple times on my Mac and am investigating what might be causing that file to remain open.

Understood. It’s nice to know I’m not alone with this error, unlike the others. Thanks.

Is it safe to delete the “Damaged” folder?
I noticed I have five “Notes.efindex” files and seven “Records.efindex” files in my “Damaged” directory. I’ve run disk diagnostics and repaired the disk directory via DiskWarrior.

To make it slightly easier to see if those utilities helped, is it safe to delete the “Damaged” folder under (filename).eflibrary:Indexes?

Yes, that’s safe.

Notes and Records Index Corruption
During “normal” operation, the Indexes folder within my eflibrary contains the following:

  1. 5 sets of files labeled XXXX.efindex and XXXX.efmailtoc (where X is an integer)
  2. IndexingState.plist
  3. A “Damaged” folder containing Notes.efindex and Records.efindex.

If I let EF start up with the files in this arrangement, EF will create Notes-1.efindex and Records-1.efindex, then spend 86 minutes reindexing everything. If I delete the XXXX.efindex and XXXX.efmailtoc files and move the Notes.efindex and Records.efindex up a directory (out of the “Damaged” folder and into the Indexes folder), EF will start up normally and not spend 86 minutes reindexing. At some point EF moves the Notes.efindex and Records.efindex files into the “Damaged” folder.

This particular eflibrary is stored on a encrypted disk image bundle. On this same disk image bundle, I store another, separate EF library, which does not have any of these issues. There’s something magically wrong with this particular eflibrary.

To summarize: 1 disk image bundle, 2 EF libraries, 1 eflibrary file has Notes.efindex and Records.efindex files that are constantly corrupting while the other eflibrary never seems to have any issues, and 1 confused user wanting to help.

Is there something I can do to help narrow in on the cause of the corruption of the Notes.efindex and Records.efindex files?

First, make sure that you’re using EagleFiler 1.5.3, as it fixes a bug where EagleFiler could think that an index file was corrupt when in fact it wasn’t.

Second, if you look in the Console log there may be some clues about why EagleFiler is unable to open Notes.efindex and Records.efindex (e.g. a file permissions problem).

Notes.efindex and Records.efindex Console Errors
You’re right. I meant to add the following:

Confirmed: EF 1.5.3

This set of lines repeats hundreds of times:

3/28/11 7:18:28 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] index.pyc:361 Couldn’t open index (exists: False): /Volumes/EagleSparseDisk/EagleLibrary/EagleLibrary.eflibrary/Indexes/Notes.efindex
3/28/11 7:18:28 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] index.pyc:364 Retrying: /Volumes/EagleSparseDisk/EagleLibrary/EagleLibrary.eflibrary/Indexes/Records.efindex
3/28/11 7:18:28 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] index.pyc:347 <NSError Domain=MJTErrorDomain Code=700 UserInfo={
3/28/11 7:18:28 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] MJTFileExists = 0;
3/28/11 7:18:28 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] MJTParentFolderModeString = 755;
3/28/11 7:18:28 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] MJTPathIsWritable = 0;
3/28/11 7:18:28 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] MJTSearchIndexOpenForWriting = 0;
3/28/11 7:18:28 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] MJTStackFrames = (
3/28/11 7:18:28 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] “-[MJTSearchIndex initWithPath:name:type:writable:phrases:error:] (245)”
3/28/11 7:18:28 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] );
3/28/11 7:18:28 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] NSFilePath = “/Volumes/EagleSparseDisk/EagleLibrary/EagleLibrary.eflibrary/Indexes/Records.efindex”;
3/28/11 7:18:28 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] NSLocalizedDescription = “The search index could not be opened.”;
3/28/11 7:18:28 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] }>
3/28/11 7:18:28 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] index.pyc:361 Couldn’t open index (exists: False): /Volumes/EagleSparseDisk/EagleLibrary/EagleLibrary.eflibrary/Indexes/Records.efindex
3/28/11 7:18:29 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] index.pyc:364 Retrying: /Volumes/EagleSparseDisk/EagleLibrary/EagleLibrary.eflibrary/Indexes/Notes.efindex
3/28/11 7:18:29 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] index.pyc:347 <NSError Domain=MJTErrorDomain Code=700 UserInfo={
3/28/11 7:18:29 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] MJTFileExists = 0;
3/28/11 7:18:29 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] MJTParentFolderModeString = 755;
3/28/11 7:18:29 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] MJTPathIsWritable = 0;
3/28/11 7:18:29 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] MJTSearchIndexOpenForWriting = 0;
3/28/11 7:18:29 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] MJTStackFrames = (
3/28/11 7:18:29 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] “-[MJTSearchIndex initWithPath:name:type:writable:phrases:error:] (245)”
3/28/11 7:18:29 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] );
3/28/11 7:18:29 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] NSFilePath = “/Volumes/EagleSparseDisk/EagleLibrary/EagleLibrary.eflibrary/Indexes/Notes.efindex”;
3/28/11 7:18:29 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] NSLocalizedDescription = “The search index could not be opened.”;
3/28/11 7:18:29 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] }>

This set of lines repeats occasionally:

3/28/11 7:18:30 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] jobs.pyc:1088 indexItem: <Note 370, None>
3/28/11 7:18:30 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] Traceback (most recent call last):
3/28/11 7:18:30 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] File “wash/jobs.pyc”, line 1084, in doOneStep
3/28/11 7:18:30 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] File “wash/jobs.pyc”, line 1241, in indexItem
3/28/11 7:18:30 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] File “wash/index.pyc”, line 679, in indexNoteIfNecessary
3/28/11 7:18:30 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] File “wash/index.pyc”, line 705, in noteNeedsIndexing
3/28/11 7:18:30 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] File “wash/index.pyc”, line 496, in containsDocument
3/28/11 7:18:30 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] File “mjt/basics.pyc”, line 227, in wrapper
3/28/11 7:18:30 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] File “wash/index.pyc”, line 395, in ensureOpen
3/28/11 7:18:30 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] File “mjt/basics.pyc”, line 227, in wrapper
3/28/11 7:18:30 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] File “wash/index.pyc”, line 390, in openIndexForReading
3/28/11 7:18:30 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] File “wash/index.pyc”, line 365, in openSearchIndex
3/28/11 7:18:30 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] File “wash/index.pyc”, line 365, in openSearchIndex
3/28/11 7:18:30 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] File “wash/index.pyc”, line 365, in openSearchIndex
3/28/11 7:18:30 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] File “wash/index.pyc”, line 377, in openSearchIndex
3/28/11 7:18:30 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] IndexOpeningError: IndexOpeningError
3/28/11 7:18:24 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] index.pyc:347 <NSError Domain=MJTErrorDomain Code=700 UserInfo={
3/28/11 7:18:24 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] MJTFileExists = 0;
3/28/11 7:18:24 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] MJTParentFolderModeString = 755;
3/28/11 7:18:24 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] MJTPathIsWritable = 0;
3/28/11 7:18:24 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] MJTSearchIndexOpenForWriting = 0;
3/28/11 7:18:24 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] MJTStackFrames = (
3/28/11 7:18:24 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] “-[MJTSearchIndex initWithPath:name:type:writable:phrases:error:] (245)”
3/28/11 7:18:24 AM [0x0-0xbf1bf1].com.c-command.EagleFiler[36454] );

Again, though EF spent 86 minutes reindexing the library, the Notes.efindex and Records.efindex files are located in the “Damaged” directory, not directly in the Indexes directory.

Just to be clear, you’ve used Disk Utility (or DiskWarrior) to repair the EagleSparseDisk volume (not just the internal hard drive), right?

I suggest quitting EagleFiler and renaming the Indexes folder to IndexesOld.