I got darwinbuild off macports to get a single unix executable (long story, see Where/how to get the Mac OSX "login" command). I was having trouble figuring out how it worked, so I tried their website's example build, "darwinbuild xnu"
It worked, and when I opened the new volume it mounted in finder, it appeared to be building a whole new mac osx (I know this is probably not the case, but that is what it looked like to me at least.) So I grabbed the binary I wanted, hit control-c in terminal, and unmounted the volume. Everything seemed to work out, but even after restarting the computer, I could not get the 2gig or so that build/mount/kernal/thing took up.
I even tried restoring a timemachine backup, but even that would not bring the free space back.
So how do I get rid of this thing once and for all?
If you know the location the files were written to, navigate there in Finder then delete them. If you don't, read the documentation that comes with the Darwin stuff you downloaded (it'll be there, believe me) to find out or download a drive space analyzer app to locate it.
Really, I don't see how these questions are about programming? They're more "how do I fix something I screwed up ancillary to programming-related efforts," which are of course superuser.com material.
Related
I try to open a file using emacs c-x c-f /Users/fred/Dropbox/foo/bar/bam/baz.txt.
In the mini buffer it says...
"File exists, but cannot be read".
...Next I do m-x revert buffer. Now in the mini buffer it says....
"Opening input file: Input/output error, /Users/fred/Dropbox/foo/bar/bam/baz.txt"
...I do m-x revert buffer again and this time the file reads in fine.
The problem is that a file should open on the first try, no questions asked!
This is more or less a repeatable problem (specifically I have gotten "File exists, but cannot be read" several times in the last 2 weeks. I try various work arounds to open the file (e.g. hit m-x revert buffer twice as described above). I usually (always?) am able to open the file. And once I finally DO open one of those obstinate files, it easily opens using emacs in other contexts (e.g. new windows, or re-opens when I have closed the buffer).
<<< UPDATE ~2 DAYS AFTER ORIGINAL POST -- START OF SECTION >>
I seem to be able to reproduce a very similar behavior when I start emacs using an init file that starts an emacs with about 30 different text files open. (I.e. part of the init is to open these files in emacs). When I change the emacs buffer (c-x b) to point to some files, call them GoodFile1, GoodFile2, there text is visible, i.e. all is well. For other files, call them BadFile1, BadFile2, BadFile3, when I switch to them the screen is blank and I know they have LOTs of text in them. I haven't seem any error messages akin to "File exists, but cannot be read", but still this is bad behavior and it seems related to the original problem. Next, similar to the originally reported case, I hit m-x revert buffer between 1 and 4(?) times and, poof!, the text appears and I am begrundgingly happy again. Now, here's the interesting bit: when I start a new terminal window and fire up an emacs loading the same init file then the formerly bad files (e.g. BadFile1, BadFile2, BadFile3) are now visible right from the start -- as they should be on a normally functioning computer. It is as if a formerly blank seeming file changes some sort of state so that when a fresh emacs tries to open it the file shows up as it should. What kind of state change is involved? I think it has to do with smart sync. So the question is, assuming it is smart sync, how to avoid this annoying required behavior of hitting revert buffer a buncha times? Does it last between boots? I am pretty sure unix touch did not help. Maybe there is some other operation to perform?
Note: On this machine I always start emacs with 'emacs -nw -l my_special_emacs_init.el' (GUI's are for wimps (-;)
<<< UPDATE ~2 DAYS AFTER ORIGINAL POST -- END OF SECTION >>
All annoying bad behavior happens on my new set up.
On my old setup, I have never gotten any thing like this behavior over years, possibly decades. (and, on my old setup, I tried the specific file mentioned above and it opened fine)
So, what, you may ask, is different between my new setup and my old setup?
OS / Hardware:
New Setup: Catalina 10.15.6 on a brand new Mac Book Pro.
Old Setup: Mohave 10.14.6 on a Mac Book Pro "early 2015" (and has never had this issue in prior OS's either)
Dropbox:
New Setup: Smart Sync On. I am using Dropbox with Smart Sync Turned on such that files are by default "online only". "online only" is a misnomer. Some files end up locally on my hard drive. Smart sync seems to figure out what files to store locally on the mac. I suspect that knowing how it does this will fix my problem.
Old Setup: Smart Sync Off. I have been using Dropbox for years but have stayed far away from Smart Sync and have never had a problem opening a file.
Emacs Version:
New Setup: GNU Emacs 27.1
Old Setup: GNU Emacs 22.1.1.
Clearly it can't be a permissions issue bc I've never had this problem on my old setup.
Any clues?
Does anyone know of any diagnostics I can do to "dig under the hood" when I find another case of this "File exists, but cannot be read".
Any thoughts on whether it is OS difference? Hardware difference? Dropbox Smart Sync Yes vs Smart Sync No difference? Emacs version difference?
<<< UPDATE ~2 DAYS AFTER ORIGINAL POST -- START OF SECTION >>
My current hunch is the the 'state change' mentioned in the update above is related to smart sync somehow figuring out that the user wants a given file cached locally. The bad behaving files are non-local so poor emacs can't open them. Whacking them with 1 to 4 revert buffers tells smart sync to make the given file local. Alas, smart sync is not smart enough to figure out what emacs users want right off the bat! Perhaps emacs can be changed in such a way as to tickle smart sync into realize that the given file should be made local local Or we can petition Dropbox to respect emacs. Or I am not using smart sync correctly. Thoughts?
<<< UPDATE ~2 DAYS AFTER ORIGINAL POST -- END OF SECTION >>
I had the same problem. This is the root cause, and solution:
https://emacs.stackexchange.com/questions/53026/how-to-restore-file-system-access-in-macos-catalina
In short, give /usr/bin/ruby full filesystem access in General Settings -> Security & Privacy -> Privacy
I had this problem on Big Sur; giving Full Disk Access to /usr/bin/ruby solved the problem.
Note it is not so trivial to do this, you have to press cmd-shift-dot in the system preferences file chooser to enable the usr directory to be visible at the Macintosh HD level.
I've implemented an OSXFUSE-based file system. It works fine on 10.8, but on Mavericks MS Word opens existing documents as blank (although I am, apparently, returning the correct data - I see the contents in the preview icon. Also, if I copy a file to a real hard drive and open it, it opens fine).
This issue is fixed on Mavericks if I mount my filesystem with the "local" flag. However, using this flag introduces other problems - e.g., it looks like it causes Finder to do some more aggressive caching, hence some file are not visible in Finder (although I can ls them in terminal).
Ideally I want to be able to mount the filesystem without this local flag (my implementation stores file on the network, so passing this flag looks wrong), but the problem with blank Word documents really puzzles me.
We have been able to track down the problem to - wait for it - Google Chrome. When Google Chrome is running while the volume is mounted, the problem appears. If Google Chrome is not running, Word/Excel/etc. files open just fine.
We've been in contact with Benjamin (OSXFUSE developer). Please also see his answer regarding this issue on the OSXFUSE mailing list:
https://groups.google.com/d/msg/osxfuse-group/URlw-n-Qakg/bLw2fHHDe7sJ
So far I have not found any bugs in osxfuse that might explain this behavior. The odd thing is that the files are not corrupted or empty. After copying the files to another volume they open just fine. Using LibreOffice to open the file on the FUSE volume works, too.
Chrome and Office seem to be based on the Carbon framework (which is deprecated since Mountain Lion). I believe the issue is somehow related to Carbon since non-Carbon apps do not seem to be affected. Every time a volume is mounted Chrome queries the volume’s capabilities and attributes (and maybe more). As far as I can tell all these file system operations return successful without any errors. But from this point on Office will fail to open documents.
In my opinion the two most likely reasons for this are:
osxfuse might break the VFS file system contract on Mavericks. I’ve been looking into this for some time now but I have not found any clues supporting this.
There might be a bug in the Carbon/CarbonCore framework. The odd thing is that there are no issues when using the stock network file systems afp or smb.
The two possible "fixes" (or rather "workarounds") for this issue seem to be (for now):
Use the "local" mount option (which might introduce other problems and is generally not recommend to use)
Do not use the "volname" mount option. The problem seems only to occur when the "volname" mount option is used. If no custom volume name is set, the problem seems not to occur and Excel/Word/etc. files open just fine - regardless whether Google Chrome was running at mount time.
I've seen the same and likewise local is not an option. Similar problems with Photoshop.
Some findings from my implementation
The problem doesn't occur on first run after reboots.
The problem begins occurring after program exit.
I solved this problem by manually dismounting (and waiting a few seconds) before exiting my program. If unmount is successful, on next run the mount again performs fine.
If the program ever terminates or dismounting fails (file in use, etc) then the volume's read-access is borked in Word/Photoshop on next mount.
Rebooting resolves issue.
Does this match what you're seeing?
I want to be able to take a snapshot of the current system and will go back to it whenever I mess up with files. I looked at the Time Machine solution, but realized that it's only a good solution when I know what file I am looking for. But sometimes, some installation process creates binary files in multiple system paths, which are very hard to locate and identify. Say I installed a package, but then I felt like I shouldn't have done that. Uninstallation might still leave files around. So What might be some of the graceful solutions to go back to a status of the machine when everything is nice and clean.
Use disk utility (Applications | Utilities)
Click on the HDD and then click on new image. You can choose to have a compressed image or not. If you don't have much stuff on the drive it shouldn't be more than 30-40GB. Once you have the dmg file, stick it somewhere for backup purposes.
Also, create a recovery disk/stick with the recovery tool.
I dunno about "graceful" but Carbon Copy Cloner is definitely an easy solution for rolling back to a previous state. You can make an exact clone of your drive, then restore it back if something goes horribly wrong. I use CCC to make periodic backups of my Macs, as a sort of secondary backup to time-machine, which is easy to use but which I don't have total confidence in.
You can restore an entire system from a Time Machine snapshot, but it requires booting from the Recovery Partition or a Recovery disk. Basically, once you've rebooted in recovery mode, you can choose Restore From Time Machine Backup and then you'll be asked to locate the drive. Once you've done that, a list of Time Machine snapshots will be presented for restoring.
I haven't done this recently, but there are indications that the time of the backups may always be in PST, so be careful when looking at the times.
While OSX comes with TimeMachine, it also has the well-known (in Linux community!) command line tool called rsync.
With Google, I'm sure you can find many articles of how to use it, though here's an interesting blog of why its author uses rsync with Time Machine.
We've got a fairly mature cross-platform game engine which we've had running on OSX for several years now without a hitch; we recently upgraded the game from SDL 1.2.15 to 2.0, and at some point in the conversion, I goofed something up and now we have a bizarre problem where the app launches just fine from the terminal, but when you launch the app from a double-click in the Finder, it just bounces once in the dock and just goes away.
We're baffled because insofar as I can tell, there's only a one-liner being printed in Console.app: Exited with code: 255 (naturally running from the terminal doesn't help here because we can't reproduce the problem there; the app runs fine when launched in a terminal).
So the only thing we can figure is it's either something we're goofing up in our main.cpp, or something we've hosed in how I set up the dylibs/frameworks. It's also possible that it's something to do with the working directory not being set right, but to the best of my abilities, I believe we're doing it right (regardless of your current working directory; the app attempts to forcibly set said directory to be in the Resources folder - this was necessary to get the game to launch, but I don't know if we're doing it wrong). This feels like a somewhat awkward fit for stackoverflow, for which I apologize, since it's not a simple "paste this code and ask what's wrong" job. I have two ways for you to reproduce it; firstly we are an open-source project, and you can get our source code (complete with a mac project file and all dependencies included in the repo, set up and ready-to-go exactly as I've perhaps erroneously created them), at our github page. The one change you'll need to do is open a file at the root level, named master-config.cfg, and remove the // comments from it (so the engine knows you want to launch a simple demo game shipped with the engine).
Alternately, I have a stripped down (~15mb zipped) binary you can directly download and try to run, if that's sufficient to diagnose the problem.
As said before, we're open-source, so we welcome any pull-requests for fixes!
You need to write a minimal Cocoa wrapper so that OS X will not SIGKILL you for not launching properly. I will give you a pull request with that wrapper.
One of my projects seems to be nearly impossible to search through in Xcode 4.3.2 on Lion lately. Using the search navigator to find anything in my project basically locks up my whole computer, with the beach ball, for 30 seconds or more.
I've tried deleting the project.xcworkspace file (which is very small anyway), and that didn't fix it. I've tried clicking on the Xcode activity viewer, but everything is locked up, so I can't see anything helpful.
With the Activity Monitor application, I can see the CPU spike when the search starts, and then it comes down to normal, and then Xcode hangs (appears as Not Responding) until it finally times out or something.
Other projects are fine. Search proceeds normally. And this only started in the last few weeks.
What I'm really worried about is a hard drive problem, but this seems very localized, and Disk Utility thinks my drive is fine.
I guess I can try making a copy of my project and searching the copy.
Has anyone seen anything like this before?!
Screenshot: Find gets stuck...
Rebuilding the code sense index didn't work either.
I did solve the problem though. The problem was a single file in my project - it seemed to be corrupt or damaged in some way. It couldn't be copied (which is how I discovered the culprit). It also couldn't be 'quick looked' or examined.
All I had to do was delete the damaged file, and revert it from my source control. And problem solved.
Now, how did it get damaged? I have no idea.