How can I stop my app from setting the "quarantine" bit? - objective-c

Ever since OS X 10.7.3, my text editor is setting the "quarantine" bit on any file it touches.
My text editor is designed for working with shell scripts, and if the quarantine bit is set then a shell script cannot be executed from the command line, until you double click it in Finder and go through a "This application was downloaded from the internet" alert (or remove the quarantine bit with xattr).
For example, I just created a "hello world" script in my app, it has been quarantined, and cannot be executed:
$ xattr -l foo
com.apple.quarantine: 0006;4f51dd2f;Dux;
$ chmod +x foo
$ ./foo
-bash: ./foo: Operation not permitted
If I remove the quarantine bit, the script works:
$ xattr -d com.apple.quarantine foo
$ ./foo
hello world
According to some forum posts, TextEdit also sets the quarantine bit on any shell script it creates.
I'm using a simple NSDocument subclass to create the file:
- (NSData *)dataOfType:(NSString *)typeName error:(NSError **)outError
{
return [self.textStorage.string dataUsingEncoding:self.stringEncoding];
}
How can I remove the quarantine bit from files created in my app? Other text editors, such a TextWrangler, do not set the quarantine bit.
UPDATE
A little more info, this only occurs when creating a "script application" file, which is anything from perl scripts to html.
And it only occurs when my app is sandboxed. Disabling sandboxing fixes the problem, but that's not a long term solution.
I've filed a bug with Radar, it looks like there might be nothing to do but wait/hope that avenue gets it fixed.

Try ensuring that the LSFileQuarantineEnabled in your Info.plist is set to false (which should be the default). If the attribute is still being set, then I'd suggest filing a bug report and removing it programmatically with removexattr(2)/fremovexattr(2)

Nice to know that I'm not the only one with this problem - which has been difficult to track-down information on. I've found this problem occurs with data files saved by my program (these are not scripts, they are just XML data...).
I confirm that LSFileQuarantineEnabled made no difference.
I also tried to remove the attribute after the file was written, using removexattr http://hints.macworld.com/article.php?story=20071029151619619, but this didn't work either - the sandbox prevented the call from working.
By way of background, I also found this discussion of the problem:
http://reviews.cnet.com/8301-13727_7-57374676-263/workarounds-for-quarantine-bug-in-os-x-lion/
For the record, I've separately raised a bug with Apple.
EDIT: I have found the source of the problem, and figured-out the work-around.
The problem was that if the file data is plain XML format data, MacOS mistakenly displays the reported message (I think this is because it wrongly assumes that the file is a script). If I change the file format to be an alternative that clearly isn't XML, the warning disappears. The file is still saved with the quarantine bit set, however!
So this is definitely due to an issue in MacOS, but there is a relatively easy work-around - just change your file format!

As far as I can tell, this bug has been fixed in OS X 10.8 (Mountain Lion).
Seems like I will have to make 10.8 the minimum OS version for my app. Not really a big deal for me... but hopefully Apple fixes it in a bugfix to 10.7 (the system requirements for 10.8 are quite a bit higher than 10.7, I know people who can't upgrade).

Related

Powerline Glyphs Overlapping

Shown in the image below, the git prompt has overlapping glyphs.
I installed this theme by following the instructions listed Here. What doesn't make sense is that all prompts other than the git prompt look completely fine. So I guess the question is why would the git extension only be affected by this glyph misalignment?
I've been trying to do my best to research into any similar issues but could not find any thing outside of questions such as this.
The environment that I am using consists of the following
Kubuntu 15.04
Konsole
Tmux
zsh
xterm-256color
oh-my-zsh
powerline status bar
powerlevel9k theme
Font : ubuntu mono derivative powerline
My .zshrc contains these two lines to engage the powerlevel9k theme
ZSH_THEME="powerlevel9k/powerlevel9k"
POWERLEVEL9K_MODE="awesome-fontconfig"
Any insights on tweaking these glyphs will be incredibly helpful. So thanks in advance!
powerlevel9k uses in "awesome-*" mode the awesome-terminal-fonts. Some of the glyphs in there are double-width, which is why we added some extra whitespace to these icons (see here). Most of us use the "awesome-patched" mode, which requires pre-patched fonts, but is easier to install.
A quick shot would be to add some more whitespace. Could you try that, and if that works add a pull request? That would be nice.
Another guess in the wild is: what locale do you use? We had some strange issues with LANG=C. If that is the case on your machine, try setting it to a proper UTF8 one.

Unable to change some files in RubyMine project

Currently I'm having an issue where I cannot make any changes to some files in my project. When hitting the return or space bar key it will only select text and not create new lines or spaces respectively.
I'm fairly certain it has something to do with the VCS features but cannot seem to find any settings to correct the Read-Only issue I'm running into.
This issue did raise it head after installing the Dash plugin. Not sure if this is coincidental or related.
Thanks!
update: After further test it looks like some files go into a sort of preview mode. Return and Space bar keys will let you scan the file and hitting any other keys will wake up the edit function. Strange?
IdealVim caused this for me. Definitely plugin related.

Why is the font in the new IntelliJ IDEA 14.1 not rendering properly?

I've just upgraded IntelliJ IDEA (ultimate) to Version 14.1 and the font used in the Project View, Menus and Dialogs seems not to be rendering correctly. I exported the same settings from my 14.0.3 version just in case, although they seem identical, but it still remained the same. I didn't do any changes to the JDK or anything, and if I run the old version the font changes back to the nice and crisp one. I am using Ubuntu 14.04. This problem does not happen on Windows 7.
Under IntelliJ IDEA 14.0.3:
Under IntelliJ IDEA 14.1:
In the new one the font seems to be a bit larger (even though in both cases I they are set to Font Size 22, and I imported the settings from the previous IntelliJ IDEA installation). Notice how for example the 'g' is cut off underneath. There are also other problems where the text is misaligned on the buttons, or not fully visible in dialog boxes.
Usually this doesn't happen when I upgrade. Is there some way to make the font look like before? Did something changed in this latest version and I need to do some JVM switch in the startup script or something?
Update: 5/11/2015
Just updated to IntelliJ 15, and the problem is still there.
Attached new screenshot. Notice how the text is cut out at the bottom where there are letters like p and y, and the button text is offset.
Seconding an earlier response to this question, I have also have had great luck fixing font rendering issues on IntelliJ using tuxjdk. Tuxjdk is a JDK for the IDE, while any applications you're coding on runs in their own project configured JDK such as Oracle or OpenJDK. Here are the instructions:
The following fetches, unpacks, and moves the version you need to /usr/lib, then cleans up the archive. Modify /usr/lib to wherever you like to keep your JDKs.
wget http://urshulyak.com:85/jdk-8u5-tuxjdk-b08.tar.gz
tar -zxvf jdk-8u5-tuxjdk-b08.tar.gz
sudo mv jdk-8u5-tuxjdk-b08 /usr/lib
rm jdk-8u5-tuxjdk-b08.tar.gz
Open up idea.sh in your IntelliJ application folder /idea-IU-141.*/bin. Change the following line at the bottom of the script from
LD_LIBRARY_PATH="$IDE_BIN_HOME:$LD_LIBRARY_PATH" "$JDK/bin/java" \
to
LD_LIBRARY_PATH="$IDE_BIN_HOME:$LD_LIBRARY_PATH" "/usr/lib/jdk-8u5-tuxjdk-b08/bin/java" \
That's it. This made huge font improvements for me in Ubuntu 14.04.
UPDATE (by OP)
This solution is the best so far (until JetBrains decide to fix it properly).
I would just add the line: IDEA_JDK="/usr/lib/jdk-8u25-tuxjdk/" to the top of idea.sh, which the script checks before resorting to JDK_HOME etc. (so is probably the recommended way) rather than messing with the LD_LIBRARY_PATH.
In my case I got nicely rendered but huge fonts with this solution. In order to fix it I had to do an extra fix from Appearance & Behaviour -> Appearance
I chose the 'not recommended' option to Override default fonts by Arial size 12. This was the best effect I got so far.
I am using OSX. It may not help.
Double tap shift and search for 'Switch IDE boot JDK'. Try different JDKs if there are.
This might not be the answer you are looking for - but ever since I've started using tuxjdk, I haven't had problems any more with font rendering & intellij on ubuntu. Maybe give it a try?
If you're willing to use the IntelliJ 15 EAP, there is an option for antialiasing (default is checked for me) that appears to match how it was rendered in 14. The option is under Appearance & Behavior -> Appearance:
I have tried all of the command-line arguments to try to get this behavior in 14.1, but was unsuccessful.

Using Preview on Mac, why does simply saving a PDF over itself with no changes made completely change the file's contents?

I have a 3 page PDF file open in Preview on the Mac. If I make no changes to the file, hit cmd-s and save the file, the binary content of the file changes heavily. Why is this?
I can tell this is the case because of my process:
make a duplicate copy of a pdf (cp a.pdf b.pdf)
vimdiff a.pdf b.pdf (no changes, exactly the same content)
open a.pdf in Preview (make no edits)
vimdiff a.pdf b.pdf (no changes, exactly the same content)
hit cmd-s (save pdf)
vimdiff a.pdf b.pdf (tons of changes, well beyond the pdf's meta-data)
Can anyone explain why/how a PDF gets "re-written" even though no changes were made?
Indeed, Preview heavily re-writes any PDF that was initially created by any non-Quartz application upon saving it for the first time.
I earn (part of) my living with debugging PDFs.
And I made it a habit now to never-ever respond to a customer with suggestions how to fix any (even the most simple) reported problem as soon as I discover the provided sample PDF has been touched by Quartz (fortunately, Apple admits its involvement by updating the /Producer metadata key with Mac OS X 10.7.4 Quartz PDFContext or similar):
because I never know if this PDF was the original PDF that exhibited the described problem, or if the customer was just trying to mail the original problem PDF via his MacBook and unintentionally re-saved + re-wrote the PDF when operating his mail app.
Therefor I always need to first establish a procedure with Apple customers which guarantees I get to analyze the original PDF files exhibiting a particular bug or problem, not the ones which where spoiled by Quartz/Preview. I've mis-spend quite some man days of work on 'analyzing' the wrong files before I discovered the problem about a year ago....
A lot of True Believers of the Apple Cult are not aware of this behavior, and a lot of prepress Pros are also completely clueless about it.
When saving a PDF the second time, chances are, that only the /ModDate metadata key is s updated (unless you're using a new version of Quartz on your Mac)... but you never know until you take a really really close look at the PDFs in question.
Update (with some additional info)
BTW, for me the simple hit on [cmd]+[s] does not yet change the PDF. But I'm on Mac OS X Lion 10.7.4, with Preview.app Version 552 (719.23). On Lion the change is triggered by saving the file under a new name (Duplicate => Save...).
k00k seems to be on Mac OS X Mountain Lion 10.8.1, with Preview.app Version 6.00 (765). For him a simple hit on [cmd]+[s] suffices to trigger the change.
(I'm not saying that the changes Apple makes to Preview-ed PDF files are necessarily bad. In quite some cases this may silently 'repair' damaged files and could be argued to be 'user-friendly' behavior. -- What I'm saying is that there are changes (whether for the good or for the bad is irrelevant) which go beyond metadata-stamping a new /ModDate value into the file, and which can make troubleshooting PDF problems very painful...)
I do not have the source code of the Preview application, so I cannot say for sure. I can guess that they are not just saving the same data that was loaded, instead it seems they are re-constructing an "equivalent" PDF file.
Additionally, when a PDF file is "re-created", there are a few items inside that will always be different (unique IDs, last date/time modification, etc).

.less: not to compile variable file

On windows I'm using WinLESS to compile my .less files but I've come across a minor issue.
I have several files which import my core variables.less file. It has nothing but variables. When WinLESS compiles, it generates a blank variables.css file as well. Is there a way to stop this blank file from being created?
If you have the latest version (1.3.0) then No, I'm afraid there isn't.
But you should raise a bug on https://github.com/dotless/dotless
I am a developer their and I'll look at it soon..
[Edit]
There is some wanted behaviour - if you change a file and it goes from being non-empty to empty, you would want it to update. However if the input file is a wildcard AND the output is empty AND the file doesn't exist, maybe it shouldn't be created.
What if there is just a bug in the less file causing it to output nothing? But this discussion should be moved to a github bug.
Are you sure your file is unchecked in winless window?
I use it as in the screenshot below and don't get empty files.