There's a similar question for iOS, but I found that the proprosed solutions do not work on macOS in all cases.
On a Mac, there are many possible Trash folders:
/.Trashes
~/.Trash
~/Library/Mobile Documents/com~apple~CloudDocs/.Trash – this one is from iCloud
/Users/xxx/.Trash – any other user's trash
/Volumes/xxx/.Trashes
This code should work but doesn't for the case of the iCloud trash:
NSURL *theURL = ...;
NSURLRelationship relationship = NSURLRelationshipOther;
NSError *error = nil;
[NSFileManager.defaultManager
getRelationship: &relationship
ofDirectory: NSTrashDirectory
inDomain: 0
toItemAtURL: theURL
error: &error];
BOOL insideTrash = !error && (relationship == NSURLRelationshipContains);
If the URL points to any iCloud folder (including the Trash folder shown above), I get this error:
Error Domain=NSCocoaErrorDomain Code=3328
"The requested operation couldn’t be completed because the feature is not supported."
Curiously, even the header file of "NSFileManager" in the 10.15 SDK suggests to use this same code:
/* trashItemAtURL:resultingItemURL:error: [...]
To easily discover if an item is in the Trash, you may use
[fileManager getRelationship:&result ofDirectory:NSTrashDirectory
inDomain:0 toItemAtURL:url error:&error]
&& result == NSURLRelationshipContains.
*/
There also seems to be an issue with trashItemAtURL: on iCloud-synched folders.
So, how do I solve this? If the Finder can detect the iCloud trash, I should be, too.
(Note: The app I use for testing this is not even sandboxed)
More findings: Fails with dead symlinks, too
The officially suggested method of using getRelationship: also fails with an error if the url points to a symlink whose target doesn't exist.
So, basically, this function is quite broken (verified in 10.13.6, 10.15.7 and 11.0.1).
Here's code to demonstrate the bug, which I've filed with Apple under FB8890518:
#import <Foundation/Foundation.h>
static void testSymlink (NSString* symlinkName, NSString* symlinkTarget)
{
NSString *path = [[NSString stringWithFormat:#"~/.Trash/%#", symlinkName] stringByExpandingTildeInPath];
NSURL *url = [NSURL fileURLWithPath:path];
symlink (symlinkTarget.UTF8String, path.UTF8String);
NSLog(#"created symlink at <%#> pointing to <%#>", url.path, symlinkTarget);
NSURLRelationship relationship = -1;
NSError *error = nil;
[NSFileManager.defaultManager getRelationship:&relationship ofDirectory:NSTrashDirectory inDomain:0 toItemAtURL:url error:&error];
NSString *rel = #"undetermined";
if (relationship == 0) rel = #"NSURLRelationshipContains";
if (relationship == 1) rel = #"NSURLRelationshipSame";
if (relationship == 2) rel = #"NSURLRelationshipOther";
NSLog(#"result:\n relationship: %#\n error: %#", rel, error);
}
int main(int argc, const char * argv[])
{
#autoreleasepool {
testSymlink (#"validSymlink", #"/System");
testSymlink (#"brokenSymlink", #"/nonexisting_file");
}
return 0;
}
With the realization that [NSFileManager getRelationship:] even fails for broken symlinks, I conclude that this is a bug in macOS that's been existing undetected for years.
I came up with the following work-around:
Use the getRelationship: operation, then check the returned error first:
If there's no error, then check if relationship == NSURLRelationshipContains, and use that as my result.
Else, in case of any error, check whether the path contains "/.Trash/" or "/.Trashes/" - if so, assume the item is inside the Trash folder.
NSURL *theURL = ...;
NSURLRelationship relationship = NSURLRelationshipOther;
NSError *error = nil;
[NSFileManager.defaultManager
getRelationship: &relationship
ofDirectory: NSTrashDirectory
inDomain: 0
toItemAtURL: theURL
error: &error];
BOOL insideTrash = !error && (relationship == NSURLRelationshipContains)
|| error && (
[theURL.path containsString:#"/.Trash/"]
|| [theURL.path containsString:#"/.Trashes/"]
)
);
Related
I am trying to use NSFileManager copyItemAtURL:toURL:error: to move a UNIX executable file (a command line program) from one directory to another but I always get an error that says the URL type is unsupported. I assume this is because without an extension on the file it is being viewed as a directory but I'm not sure. Is it possible to move this type of file with NSFileManager?
Edit:
Here is my code
#define SAVE_DIR [#"~/Library/Prog" stringByExpandingTildeInPath]
#define PROG_PATH [SAVE_DIR stringByAppendingString:#"/ProgCom"]
#define RESOURCES [[NSBundle mainBundle] resourcePath]
#define LOCAL_PROG [RESOURCES stringByAppendingString:#"/ProgCom"]
-(void)moveProg
{
NSError *error = nil;
NSURL *fromURL = [NSURL URLWithString:LOCAL_PROG];
NSURL *toURL = [NSURL URLWithString:PROG_PATH];
NSLog(#"%#", [fromURL path]);
NSLog(#"%#", [toURL path]);
if ([fMan fileExistsAtPath:[fromURL path]]) {
[fMan copyItemAtURL:fromURL
toURL:toURL
error:&error];
if (error)
[NSApp presentError:error];
}
}
The error I receive:
The file couldn't be opened because the specified URL type isn't supported.
And finally what gets logged:
fromURL = /Users/Nick/Library/Developer/Xcode/DerivedData/Prog-dpnblqaraeuecyadjgizbinfrtcm/Build/Products/Debug/Prog.app/Contents/Resources/ProgCom
toURL = /Users/Nick/Library/Prog/ProgCom
The problem is you're using +[NSURL URLWithString:]. This is producing an invalid URL, since you're not actually giving it one. What you want is +[NSURL fileURLWithPath:], which will produce a file:///Users/Nick/... URL.
I'm trying to make a Mac OS X application that asks the user for a directory. I'm using an NSOpenPanel that gets triggered when the user presses a "Browse" button.
The problem is, [NSOpenPanel filenames] was deprecated, so now I'm using the URLs function. I want to parse out the stuff that's url related to just get a normal file path. So I tried fileName = [fileName stringByReplacingOccurrencesOfString:#"%%20" withString:#" "];, but that gave me an error:
-[NSURL stringByReplacingOccurrencesOfString:withString:]: unrecognized selector sent to instance 0x100521fa0
Here's the entire method:
- (void) browse:(id)sender
{
int i; // Loop counter.
// Create the File Open Dialog class.
NSOpenPanel* openDlg = [NSOpenPanel openPanel];
// Enable the selection of files in the dialog.
[openDlg setCanChooseFiles:NO];
// Enable the selection of directories in the dialog.
[openDlg setCanChooseDirectories:YES];
// Display the dialog. If the OK button was pressed,
// process the files.
if ( [openDlg runModal] == NSOKButton )
{
// Get an array containing the full filenames of all
// files and directories selected.
NSArray* files = [openDlg URLs];
// Loop through all the files and process them.
for( i = 0; i < [files count]; i++ )
{
NSString* fileName = (NSString*)[files objectAtIndex:i];
NSLog(#"%#", fileName);
// Do something with the filename.
fileName = [fileName stringByReplacingOccurrencesOfString:#"%%20" withString:#" "];
NSLog(#"%#", fileName);
NSLog(#"Foo");
[oldJarLocation setStringValue:fileName];
[self preparePopUpButton];
}
}
}
Interestingly enough, "Foo" never gets outputted to that console. It's like the method aborts at the stringByReplacigOccurencesOfString line.
If I remove that one line, the app will run and fill my text box with the string, just in URL form, which I don't want.
Your problem is that the NSArray returned by [NSOpenPanel URLs] contains NSURL objects, not NSString objects. You're doing the following cast:
NSString* fileName = (NSString*)[files objectAtIndex:i];
Since NSArray returns an id, there isn't any compile-time checking to make sure your cast makes sense, but you do get a runtime error when you try to send an NSString selector to what is actually an NSURL.
You could convert the NSURL objects to NSString and use your code mostly as-is, but there's no need for you to handle the URL decoding yourself. NSURL already has a method for retrieving the path portion which also undoes percent-encoding: path.
NSString *filePath = [yourUrl path];
Even if your code was dealing with just a percent-encoded NSString, theres stringByReplacingPercentEscapesUsingEncoding:.
I've got a Cocoa command-line app which is built to target 10.5 SDK. In the app, I have
NSString *appPath = [[NSBundle mainBundle] bundlePath];
NSLog(#"%#", appPath);
On Mac OSX 10.5, when I run the app from the command line, I get the expected output of the path. However, if I set the app up to run as a LaunchDeamon, it only outputs a '/'
It works as expected on 10.6 and on 10.7 both as a Deamon and as an app. Anyone know why the difference would be? Is there a better way to get the application path that would work on 10.5+?
UPDATE
For me, the solution in the accepted answer did not work. However, the comment about adding the "WorkingDirectory" key to the LaunchDeamon's plist file worked out. Apparently this is needed for Mac OS X 10.5, but not 10.6+.
Thanks for answering my clarifying question.
NSBundle depends on a existing bundle, with it's associated Info.plists and bundle ID's (e.g. com.apple.textedit.app), etc.
While a single binary is not a bundle, I'm guessing that Apple engineering fixed up [[NSBundle mainBundle] bundlePath] to do "the right thing" in 10.6 & 10.7. But you still need a solution for 10.5.
Maybe the UNIX library function char * getcwd(char *buf, size_t size) would get you to where you need to be.
For a proper solution, I'd recommend doing a run-time conditional check with code that looks something like this:
+ (NSString *) getAppPath
{
NSString * appPath = NULL;
SInt32 minorVersionNum;
OSErr err;
err = Gestalt(gestaltSystemVersionMinor,&minorVersionNum);
// do this only if we're running on anything *older* than 10.6
if((noErr == err) && (minorVersionNumber < 6))
{
// hopefully the below define is enough space for any returned path
#define kMaxPathLength 512
size_t bufferLength = kMaxPathLength;
char bufferToHoldPath[kMaxPathLength];
// initialize the buffer & guarantee null-terminated strings
bzero(&bufferToHoldPath,bufferLength);
if( getcwd(&bufferToHoldPath, bufferLength) != NULL)
{
appPath = [NSString stringWithUTF8String: bufferToHoldPath];
}
}
// this code runs for 10.6 and *newer*, and attempts it on
// 10.5 only if the above getcwd call failed
if(NULL == appPath)
{
appPath = [[NSBundle mainBundle] bundlePath];
}
return(appPath);
}
I did not test this code out so YMMV.
I have a zipped file, which i want to extract the contents of it. What is the exact procedure that i should do to achieve it. Is there any framework to unzip the files in cocoa framework or objective C.
If you are on iOS or don't want to use NSTask or whatever, I recommend my library SSZipArchive.
Usage:
NSString *path = #"path_to_your_zip_file";
NSString *destination = #"path_to_the_folder_where_you_want_it_unzipped";
[SSZipArchive unzipFileAtPath:path toDestination:destination];
Pretty simple.
On the Mac you can use the built in unzip command line tool using an NSTask:
- (void) unzip {
NSFileManager* fm = [NSFileManager defaultManager];
NSString* zipPath = #"myFile.zip";
NSString* targetFolder = #"/tmp/unzipped"; //this it the parent folder
//where your zip's content
//goes to (must exist)
//create a new empty folder (unzipping will fail if any
//of the payload files already exist at the target location)
[fm createDirectoryAtPath:targetFolder withIntermediateDirectories:NO
attributes:nil error:NULL];
//now create a unzip-task
NSArray *arguments = [NSArray arrayWithObject:zipPath];
NSTask *unzipTask = [[NSTask alloc] init];
[unzipTask setLaunchPath:#"/usr/bin/unzip"];
[unzipTask setCurrentDirectoryPath:targetFolder];
[unzipTask setArguments:arguments];
[unzipTask launch];
[unzipTask waitUntilExit]; //remove this to start the task concurrently
}
That is a quick and dirty solution. In real life you will probably want to do more error checking and have a look at the unzip manpage for fancy arguments.
Here's a Swift 4 version similar to Sven Driemecker's answer.
func unzipFile(at sourcePath: String, to destinationPath: String) -> Bool {
let process = Process.launchedProcess(launchPath: "/usr/bin/unzip", arguments: ["-o", sourcePath, "-d", destinationPath])
process.waitUntilExit()
return process.terminationStatus <= 1
}
This implementation returns a boolean that determines if the process was successful or not. Is considering the process successful even if warnings were encountered.
The return condition can be changed to return process.terminationStatus == 0 to not even accept warnings.
See unzip docs for more details on diagnostics.
You can also capture the output of the process using a Pipe instance.
func unzipFile(at sourcePath: String, to destinationPath: String) -> Bool {
let process = Process()
let pipe = Pipe()
process.executableURL = URL(fileURLWithPath: "/usr/bin/unzip")
process.arguments = ["-o", sourcePath, "-d", destinationPath]
process.standardOutput = pipe
do {
try process.run()
} catch {
return false
}
let resultData = pipe.fileHandleForReading.readDataToEndOfFile()
let result = String (data: resultData, encoding: .utf8) ?? ""
print(result)
return process.terminationStatus <= 1
}
If you just want to unzip the file, I would recommend using NSTask to call unzip(1). It's probably smart to copy the file to a directory you control -- probably in /tmp -- before unzipping.
Here's a more concise version based on codingFriend1's approach
+ (void)unzip {
NSString *targetFolder = #"/tmp/unzipped";
NSString* zipPath = #"/path/to/my.zip";
NSTask *task = [NSTask launchedTaskWithLaunchPath:#"/usr/bin/unzip" arguments:#[#"-o", zipPath, #"-d", targetFolder]];
[task waitUntilExit];
}
-d specifies the destination directory, which will be created by unzip if not existent
-o tells unzip to overwrite existing files (but not to deleted outdated files, so be aware)
There's no error checking and stuff, but it's an easy and quick solution.
Try Zip.framework.
-openFile: (NSWorkspace) is the easiest way I know.
I'm using an OpenPanel to get a file path URL. This works:
[oPanel beginSheetModalForWindow:theWindow completionHandler:^(NSInteger returnCode)
{
NSURL *pathToFile = nil;
if (returnCode == NSOKButton)
pathToFile = [[oPanel URLs] objectAtIndex:0];
}];
This doesn't, resulting in an 'assignment of read-only variable' error:
NSURL *pathToFile = nil;
[oPanel beginSheetModalForWindow:theWindow completionHandler:^(NSInteger returnCode)
{
if (returnCode == NSOKButton)
pathToFile = [[oPanel URLs] objectAtIndex:0];
}];
return pathToFile;
In general, any attempt to extract pathToFile from the context of oPanel has failed. This isn't such a big deal for small situations, but as my code grows, I'm forced to stuff everything -- XML parsing, core data, etc -- inside an inappropriate region. What can I do to extract pathToFile?
Thanks.
This doesn't, resulting in an 'assignment of read-only variable' error:
NSURL *pathToFile = nil;
[oPanel beginSheetModalForWindow:theWindow completionHandler:^(NSInteger returnCode)
{
if (returnCode == NSOKButton)
pathToFile = [[oPanel URLs] objectAtIndex:0];
}];
return pathToFile;
Yes, because you're trying to assign to the copy of the pathToFile variable that gets made when the block is created. You're not assigning to the original pathToFile variable that you declared outside the block.
You could use the __block keyword to let the block assign to this variable, but I don't think this will help because beginSheetModalForWindow:completionHandler: doesn't block. (The documentation doesn't mention this, but there's no reason for the method to block, and you can verify with logging that it doesn't.) The message returns immediately, while the panel is still running.
So, you're trying to have your completion-handler block assign to a local variable, but your method in which you declared the local variable will probably have returned by the time block runs, so it won't be able to work with the value that the block left will leave in the variable.
Whatever you do with pathToFile should be either in the block itself, or in a method (taking an NSURL * argument) that the block can call.
you can also runModal after you begin the sheet you just need to make sure you end the sheet later. This way you don't have to bend to apple's will, it isn't deprecated and it should still work perfectly.
NSOpenPanel *openPanel = [NSOpenPanel openPanel];
[openPanel beginSheetModalForWindow:window completionHandler:nil];
NSInteger result = [openPanel runModal];
NSURL *url = nil;
if (result == NSFileHandlingPanelOKButton)
{
url = [openPanel URL];
}
[NSApp endSheet:openPanel];
It seems a little bit like black magic coding but it does work.