moveItemAtURL:toURL:error
The new location for the item in srcURL. The URL in this parameter must not be a file reference URL and must include the name of the file or directory in its new location. This parameter must not be nil.
Given the above restriction, in what circumstances would a fileReferenceURL be useful?
fileURL is a file's path at which file is present and to access it we need to fetch that file using its fileURL.
On the other hand fileReferenceURL points to the file directly rather than its location. So if file is moved the fileURL will change with that so we need to keep checking for fileURL if we want to access it, but fileReferenceURL will stay the same.
According to doc about fileReferenceURL:
A file reference URL's path should never be persistently stored, because it is not valid across system restarts or remounts of volumes
So basically to move a file you need a path (fileURL) and not the reference of the file (fileReferenceURL).
Related
I currently have a file in my project directory in Xcode. I am new to swift and all I would like to do is check if the file exists.
Picture of project directory
I created a resources directory and put it in the project. I added my file "GEOJson.json" and I just want to check for its existence and have a boolean value returned.
I am eventually going to need to read from the JSON file and import the contents into my project.
Extra:
Eventually this file is going to need to be pulled from a remote server as it will be constantly updating and inside it will be objects with GPS coordinates that need to be added to my map kit. The GEOJson file will be sitting on a mesh network that we set up and the app will need to pull the file off a directory on the network when connected to it and update the map. The end goal is that the file's existence is checked for on the server, if it exists it will be pulled periodically and the contents will update said map markers. If anybody has any idea how to do this the help would be much appreciated!
You can try this
if let file = Bundle.main.path(forResource: "GEOJson", ofType: "json", inDirectory: "Resources") {
print(file)
}
//
If you want to edit it then you have to copy / download - it out of main Bundle say in Documents , then process it there
I'm trying to save a downloaded file so I can open it in another session. I'm saving the mp3 data to the documents directory, and I'm saving the url to the file in a local datastore. When I check using
if ([[NSFileManager defaultManager] fileExistsAtPath:musicObject[#"localFile"]]){
NSLog(#"applicationDocumentsDir exists");
}
else {
NSLog(#"File doesn't exist");
}
it returns "File doesn't exist", but I know it does because I've printed out the documents directory which gives me
"file:///private/var/mobile/Containers/Data/Application/94552DFC-022B-4962-9CB7-CCD87CB43E57/Documents/xDDsCbXAFhwEqGIzJfJRByEr1.mp3",
and I'm trying to access it with the same path but the first is private. How do I make the file not private (I have saved it earlier in the app)
file:///var/mobile/Containers/Data/Application/AE27BD8F-5EEB-48FC-A8D4-E228F99CECE3/Documents/xDDsCbXAFhwEqGIzJfJRByEr1.mp3
I suggest the following steps:
Take the last path component (that's just your mp3 filename)
Get the current Documents directory
Build a new path with the current Documents directory and the extracted mp3 filename
If I remember correctly, /var is a symlink to /private/var. So depending on how the path is built, one may end up with one or the other.
I inherited a project which was struck by the same problem, only with an extra randomly named directory in between. Eventually I removed the leading /private component, constructed an array of path components and checked, whether replacing non-existent elements with the current value leads to an existing file. You case should be easier to handle.
I don't remember when, but at some point the application directory (the hex numbers path component) began to change with almost each run in the simulator. Beginning with this behaviour such problems became much more visible. Although one should not save full paths, I suspect a lot of projects didn't care in the past. On one hand because things just worked, and on the other hand because a lot of people just don't know it.
I have a file that describes input data, which is split into several other files. In my descriptor file, I first give the path A that tells where all the other files are found.
The originator may set either a relative (to location of the descriptor file) or absolute path.
When my program is called, the user gives the name of the descriptor file. It may not be in the current working directory, so the filename B given may also contain directories.
For my program to always find the input files at the right places, I need to combine this information. If the path A given is absolute, I need to just that one. If it is relative, I need to concatenate it to the path B (i.e. directory portion of the filename).
I thought boost::filesystem::complete may do the job for me. Unfortunately, it seems it is not. I also did not understand how to test wether a path given is absolute or not.
Any ideas?
Actually I was quite misguided first but now found the solution myself. When "base" holds the path A, and filename holds B:
boost::filesystem::path basepath(base), filepath(filename);
if (!basepath.is_complete())
basepath = filepath.remove_leaf() /= basepath;
base = basepath.string();
It works with Linux at least (where it would be very easy to do without boost, but oh well..), still have to test with Windows.
For me, a path was always something that "walks the way to something", but without the "something".
Like a chicken following bread crumbs until it hits the target. But the target is not part of the path. That's what I believe.
So, example: C:/foo/bar = the path. C:/foo/bar/something.html = Path and the "Target".
Can someone tell me what are the correct terms here? How do I call such a path with file?
"Full path"?
"Full qualified path"?
"Path with File Name"? (not precise! "Path with File Name and Extension" ... way too long)
Sure there's a special name for this. Want to know! :)
Nice chicken example... I think you mean absolute path
but, It doesn't matter what the path points to, be it a directory, file, device or otherwise
Wikipedia says:
A path, the general form of a filename or of a directory name, specifies a unique location in a file system.
It doesn't even require an extension, as other mechanisms work out the filetype.
/foo/bar/file.txt = Absolute path
/foo/bar = An absolute path to a directory
../foo = A relative path to a directory, from current directory
./file.txt = A relative path to a file, from current directory (Unix)
file.txt = A relative path too
Also
Systems can use either absolute or relative paths. A full path or absolute path is a path that points to the same location on one file system regardless of the working directory or combined paths. It is usually written in reference to a root directory.
The distinction between files and directories isn't catered for with a path. A path is always a path to something, be it a file or a directory:
/a/b/c is the path to c regardless of what type (file, directory, device) the end point is.
Also checkout basenames
basename is a standard UNIX computer program, when basename is given a pathname, it will delete any prefix up to the last slash ('/') character and return the result. basename is described in the Single UNIX Specification and is primarily used in shell scripts.
From LINFO
A path is the address of an object
(i.e., file, directory or link) on a
filesystem.
So, unfortunately, you are looking for a specificity of terms that isn't part of the accepted usage. You'll have to define your own terms.
I beleive it is called "full name" regardless of the "target" type, just because everything in UNIX is a file, including a directory. So if a foo is the target (as you called it), then foo is the name, while C:\Direcotry\foo or /usr/bin/foo is the foo's full name.
i have been thinking about it too lately, because in Everything, the path do not include the "target" itself. but when i search in Wikipedia, it say that the target is included.
in your example, you have implicitly assume that there is "only one" target at the end of the bread crumbs. and someone tell the chicken to follow the bread crumbs and then it can get to the target.
what if there are 2 objects in the end? if someone did not tell which one is the target, e.g. include the target itself in the path, the chicken will never know its target.
you can also think like this: for a path which include the file, the target is not the file, but its content or some other imformation of the file.
back to the file system, assume there is several file in a folder. if file name is not included in its path, then they all have same path and you can not find a specific file through its path alone.
I have a problem loading a file, as I'm passing a relative path to the function FileExists(Filename: String) and it's returning false, that is, it does not find the file in the directory that I pass.
I have a file named Template.html in the D:\Programming\Delphi\Projects\SendMail directory, and a service written in Delphi whose .EXE is in the D:\Programming\Delphi\Automation directory. I am passing the relative path: .\..\Projects\SendMail\Template.html to FileExists(), but it's returning that the file does not exist.
I think that has something to do with the relative path of a service and the relative path of the application being different. Can anybody help me with this?
As lorenzog said, try specifying the full path.
You can also try to set the currentdir to your likings.
//sets currentdir to your application.exe dir
SetCurrentDir(ExtractFileDir(ParamStr(0)));
You assume that the current directory of the service is the directory the executable is stored in. Call GetCurrentDir to find out the current directory.
My experience has been that services start with a working folder of %SystemRoot%\System32 no matter where the actual executable is located.
The way that I have got around this limitation is to write a registry key during installation of the service (e.g. HKLM\SOFTWARE\MyCompany\MyApp\INSTALL_PATH) that points to what I would like the working folder to be. Then when the service starts, it grabs the data from the registry and uses that value as the base when creating paths to files.