An open community 
of Macintosh users,
for Macintosh users.

FineTunedMac Dashboard widget now available! Download Here

Previous Thread
Next Thread
Print Thread
Bizarre disk image behavior
#35775 08/26/15 10:59 AM
Joined: Aug 2009
Likes: 15
OP Online

Joined: Aug 2009
Likes: 15
(OS X 10.6.8) I store my passwords database in a Text Edit doc in an encrypted sparse disk image (disk image).

A while ago I spaced out and ejected the disk image while the Text Edit doc was still open.

When I realized what I had done I frustratingly unsuccessfully tried to quit Text Edit both with and without the disk image mounted, and finally "killed" it in Terminal. (I don't know why it didn't occur to me to try to force quit it.)

The aftermath is that Text Edit is now somehow connected to the disk image...even after I trashed the original and created a new one (same name, same location).

ANY Text Edit doc I try to open calls up a password dialog box for the disk image, and, and this is weird, after I hit "Cancel" four times the doc opens.

OK, brainstorm... I just created a new disk image...different name, same location and trashed the first one, and Text Edit docs now behave as expected.

But can anybody explain what happened with the first disk image?

Update: I just created another disk image with the original name (giving me two), and Text Edit docs still open as expected.

Update 2: Spoke too soon. The docs only open if the disk image is in a different location than it was in when the debacle occurred; Text Edit stopped working when I moved it to its original location.

confused crazy


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Bizarre disk image behavior
artie505 #35786 08/27/15 03:34 AM
Joined: Aug 2009
Likes: 15
OP Online

Joined: Aug 2009
Likes: 15
Update 3: I reset my LaunchServicesDatabase and shut down, and after starting up I created a new disk image with the same name and in the same location, and it, too, is married to Text Edit.

Update 4: A new disk image - same name, same location - created after running DiskWarrior exhibited the same bizarre behavior.

It looks like TextEdit and /Volumes/HD2/Clutter/Passwords.sparseimage are inextricably married.


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Bizarre disk image behavior
artie505 #35788 08/27/15 07:58 AM
Joined: Aug 2009
Offline

Joined: Aug 2009
Sounds to me like TextEdit keeps looking for the file. Have you trashed the app's preferences? I did a search for textedit files and folders: it has stuff littered all over.


iMac (19,1, 3.1 GHz i5, 12.7.4, 40 Gb RAM); MacBook Air (1.8 Ghz, 8 Gb RAM, 10.14.6, 256 Gb SSD) Vodafone router and Devolo Wi-Fi Extender, Canon TS8351 printer/scanner.
Re: Bizarre disk image behavior
freelance #35790 08/27/15 08:19 AM
Joined: Aug 2009
Likes: 15
OP Online

Joined: Aug 2009
Likes: 15
Thanks for the thought.

I trashed TextEdit's plist and restarted...with no joy, and I followed that with trashing TE's cache (Edit: and restarting), also with no joy.

I just discovered that even opening a new TE doc calls up the password dialog box, but it only takes two "Cancels" as opposed to the four it takes to open a populated doc.

Weirder and weirder!!! confused crazy

Last edited by artie505; 08/27/15 09:03 AM.

The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Bizarre disk image behavior
artie505 #35791 08/27/15 08:41 AM
Joined: Aug 2009
Likes: 15
OP Online

Joined: Aug 2009
Likes: 15
Just trashed TextEdit and replaced it from a month old clone...no joy.


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Bizarre disk image behavior
artie505 #35793 08/27/15 12:52 PM
Joined: Aug 2009
Offline

Joined: Aug 2009
it sounds like it is attempting to populate it's "recent items" list. It won't include items in the list that are not currently accessible, so it has to sweep through the list before it can display the menu, something it may do on app launch.

I thought that data was stored in the prefs file. But OS X now caches prefs with a daemon, and that may be griefing you.

1. reboot
2. DO NOT launch text edit
3. find and delete the textedit plist
4. empty trash
5. reboot

see if you can now launch textedit peacefully


I work for the Department of Redundancy Department
Re: Bizarre disk image behavior
artie505 #35795 08/27/15 01:31 PM
Joined: Aug 2009
Likes: 1
Offline

Joined: Aug 2009
Likes: 1
Originally Posted By: artie505
Thanks for the thought.

I trashed TextEdit's plist and restarted...with no joy, and I followed that with trashing TE's cache (Edit: and restarting), also with no joy.

I just discovered that even opening a new TE doc calls up the password dialog box, but it only takes two "Cancels" as opposed to the four it takes to open a populated doc.

Weirder and weirder!!! confused crazy


It's doing this when it attempts to fill the Open Recent menu. Run TextEdit, click the File menu, go to Open Recent, and choose Clear Menu from the bottom.


Photo gallery, all about me, and more: www.xeromag.com/franklin.html
Re: Bizarre disk image behavior
tacit #35799 08/27/15 06:37 PM
Joined: Aug 2009
Offline

Joined: Aug 2009
removing the plist should fix that, that's where recent items are stored, they are not managed globally. (though they do use a standardized structure)

My directions above list the process required to get aound cfprefsd's pesky "being helpful" caching of preferences. Basically when an app tries to load a pref, the daemon opens it on the app's behalf, and caches it. It does this because some apps are continuously reading/writing to their prefs file when they don't need to be. It buffers this and dumps it when the app exits. Even if the app crashes, it gets written because it's the daemon doing the writing. (it also reduces disk read/write power requirements and also helps avoid flash cell wear) But if you open the app, verify the issue, close the app, modify the pref, and reopen the app, it will pull the cached data because cfprefsd can hold onto it and overwrite the file (and your changes / deletion) minutes or even hours later.

The best way to avoid that is to not launch the app after reboot. trash the pref before the daemon gets wind of it being accessed. You can kill the daemon but I've had mixed success with that approach. (as have others) Note that if you use the "approved" access methods (defaults write) it goes through the daemon. But that's not useful for WIPING the prefs file.


I work for the Department of Redundancy Department
Re: Bizarre disk image behavior
tacit #35801 08/28/15 05:13 AM
Joined: Aug 2009
Likes: 15
OP Online

Joined: Aug 2009
Likes: 15
Thanks, but "Open Recent" is unpopulated..."Clear Menu" is grayed out.


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Bizarre disk image behavior
Virtual1 #35802 08/28/15 05:20 AM
Joined: Aug 2009
Likes: 15
OP Online

Joined: Aug 2009
Likes: 15
I'm running 10.6.8 in which I don't think cfprefsd has been fully implemented.

In my first stab at the plist I quit TextEdit, trashed the plist, and restarted, and I believe that was a successful effort, because the next time I launched TE my prefs had reverted to default.

Be that as it may, though, I just followed your instructions, and trying to launch TE still calls up the password dialog box for that disk image. frown


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Bizarre disk image behavior
artie505 #35803 08/28/15 10:18 AM
Joined: Aug 2009
Likes: 3
Moderator
Online
Moderator

Joined: Aug 2009
Likes: 3

Quote:
A while ago I spaced out and ejected the disk image while the Text Edit doc was still open.

I think what might have happened is that you made some changes, however innocuous, to your open document before ejecting the disk image, and these changes were recorded by TextEdit's autosave function. Such autosaved versions are normally scrubbed when you quit the app (if you haven't manually saved in the interim, you'll get the "save changes?" dialog); but since you ejected the disk image without having quit the app, TextEdit begins subsequent launches with a quest to open the document in the changed state it was in when it was so rudely closed.

The autosaved version appears, in Snow Leopard, to be kept in ~/Library/Autosave Information. (There should be a .plist and one or more documents; the .plist maintains the location of the original files for which the autosaved versions were recorded.) My surmise is that you can put an end to the anomalous behavior by trashing the autosaved version, or perhaps by editing or trashing the .plist, but I make no guarantees!

Last edited by dkmarsh; 08/28/15 10:39 AM. Reason: formatting


dkmarsh—member, FineTunedMac Co-op Board of Directors
Re: Bizarre disk image behavior
dkmarsh #35814 08/30/15 04:48 AM
Joined: Aug 2009
Likes: 15
OP Online

Joined: Aug 2009
Likes: 15
Bingo...sorta!!!

You're correct about my having changed my doc, and trashing /Users/artie/Library/Autosave Information/com.apple.TextEdit.plist - no other files at that location - got things back to normal, but I was unable recreate my problem, so I'm not sure what, specifically, brought it on.

Sorry for totally forgetting about having changed the doc when I posted.

Thanks for helping me get things back to normal! smile


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire

Moderated by  alternaut, dkmarsh, joemikeb 

Link Copied to Clipboard
Powered by UBB.threads™ PHP Forum Software 7.7.4
(Release build 20200307)
Responsive Width:

PHP: 7.4.33 Page Time: 0.036s Queries: 38 (0.024s) Memory: 0.6304 MB (Peak: 0.7327 MB) Data Comp: Zlib Server Time: 2024-03-29 00:43:25 UTC
Valid HTML 5 and Valid CSS