I am writing a Blackberry 10 Cascades app. I am trying to open a file which is an email attachment.
int in_fd = open(m_uri.replace("file://","").toUtf8().constData(), O_RDONLY);
(There's a reason I am using the open() call)
But the file cannot be opened. I understand that this is to do with sandboxing and app permissions, and that the Invocation framework can make a copy of the file in the target app's directory. What I can't figure out is how to get the path to that file so that I can open it.
I need to know:
How to make sure the Invocation Framework copies the file to my apps sandbox on invocation.
How to access the resulting copied file.
In C++
Can you print an example of what is contained inside m_uri when your code runs?
If the path you are feeding open() does not have a leading /, then it will look from the app's home directory which is not what you want.
Related
I am trying to read a file in a test/debug UWP application that is being deployed to Hololens. I can put the file on the device with the device portal, but am unable to find the correct path to open the file.
I am using the MSFT BasicXrApp_uwp example as a basis, and have included FileUtility which has a FindFileInAppFolder function. This is consistently failing to find the file, with the error:
"The file should be embeded in app folder in debug build.",
after letting me know the app folder is:
C:\Data\Users\DefaultAccount\AppData\Local\DevelopmentFiles\364f83f4-6e13-42e4-8253-71dd3040951cVS.Debug_ARM.mikeh\
The part 364f83f4-6e13-42e4-8253-71dd3040951cVS is recognisable in the device portal as the User Folders/LocalAppData folder, but the Debug_ARM.mikeh part is not visible on the portal.
I am using C++ and trying to do the file reading in a static, non uwp library if possible (pointing that out so I don't get suggestions to use UWP async stuff, if that is possible).
So, how do I embed my file in the app folder, or how do I place the file so I can read it?
This is because the folder path which FindFileInAppFolder method returns is the InstalledLocation of the current package, but what you checked in the device portal is LocalFolder/LocalCacheFolder, for more information about what different between them please see: File access permissions.
how do I embed my file in the app folder, or how do I place the file so I can read it?
You can place your file in the LocalState folder by Device Portal and get this folder path through ApplicationData.LocalFolder Property, the path should be like: C:\Data\Users\DefaultAccount\AppData\Local\Packages\364f83f4-6e13-42e4-8253-71dd3040951c\LocalState. For how to access the files via C++ you can use for example File access sample
I'm using an answer here as there's more room than a comment.
I found a few extra things useful. I added in the cppWinRT nuget package to my application.
I did need to use the "async stuff", for example:
using namespace winrt;
using namespace Windows::Foundation;
using namespace Windows::Storage;
StorageFolder storageFolder= KnownFolders::GetFolderForUserAsync(nullptr, KnownFolderId::PicturesLibrary).get();
This let me find a file I'd uploaded ot the Pictures Library. But I couldn't open it after passing the path to my existing library:
const auto sampleFile = storageFolder.GetFileAsync(fileName).get();
std::wstring path = sampleFile.Path();
MyLibraryCall(to_string(path));
MyLibraryCall would try and open an ifstream, and even using std::ifstream::in would fail.
So I copied the file to the temp directory, where I could open it and process it.
This is pretty hacky but it did what I needed, which is let me load an .obj file that was rejected by the 3D parts viewer.
The loop over all filenames is because storageFolder.GetFileAsync(fileName).get() throws an exception if it fails, which for me I could not catch properly.
StorageFolder tempFolder = Windows::Storage::ApplicationData::Current().TemporaryFolder();
std::wstring path;
auto files = tempFolder.GetFilesAsync().get();
for (auto file : files)
{
if (file.Name() == fileName) {
path = file.Path();
break;
}
}
if (!path.size()) {
// hasn't been copied into temp
StorageFile movedFile = sampleFile.CopyAsync(tempFolder).get();
path = movedFile.Path();
}
MyLibraryCall(to_string(path));
Anyway- not the greatest but that will hopefully help someone else looking for a quick and dirty way to process a file on a hololens/UWP app.
I have an xcode project, the used language is C++. while my program is running writes a txt file in to
My App.app/Contents/Resources/
folder using fstream. After a month pause don't work anymore. Nothing is modified on the project but the OS X is updated. The file path is ok, i can read the file. What is wrong?
You should not write into your app bundle, and instead use one of the following folders to store files, which can be obtained using NSSearchPathForDirectoriesInDomains:
Document folder (NSDocumentDirectory).
Application Support folder (NSApplicationSupportDirectory).
Caches folder (NSCachesDirectory).
If you write to your app bundle you will cause issues with the code signing of the app and might not even have write access, if it's installed in the default location (/Applications).
I have deployed my webapplication on a jetty server, and I am trying to edit those deployed files using WebStorm 8.0.4. But I am unable to save the edited files and getting the following error:
Try turning the 'safe write' feature (Settings/General, 'Use safe writes') off - does it help? It creates a temporary copy of a file: creates a separate temp file, deletes the original and then renames. With this option the original file permissions may be lost, this causes problems, especially when working on remote drives.
Follow these steps.
Open C:\Users\YourUserName\.m2\repository (If you use maven)
Find org folder and Navigate org\eclipse\jetty\jetty-webapp\yourJettyVersion
There will be a .jar file.
Open it with winrar or some program like winrar.
Navigate org\eclipse\jetty\webapp
Find webdefault.xml and Open it with any text editor.
Search useFileMappedBuffer parameter in file
You will see a param value.
Change it to false.
Save and Exit.
I'm sorry for any English mistakes.
I want to write a log file for my application. The path where I want to store the file is:
destination::"C:\ColdFusion8\wwwroot\autosyn\logs"
I have used the sample below to generate the log file:
<cfset destination = expandPath('logs')>
<cfoutput>destination::"#destination#"</cfoutput><br/>
<cflog file='#destination#/test' application="yes" text="Running test log.">
When I supply the full path, it didn't create a log file. When I remove my destination, and only provide a file name, the log is generated in the ColdFusion server path C:\ColdFusion8\logs.
How can I generate a log file in my application directory?
Here is the description of attribute file according to cflog tag specs:
Message file. Specify only the main part of the filename. For example,
to log to the Testing.log file, specify "Testing".
The file must be located in the default log directory. You cannot
specify a directory path. If the file does not exist, it is created
automatically, with the extension .log.
You can use cffile tag to write information into the custom folder.
From the docs for <cflog>:
file
Optional
Message file. Specify only the main part of the filename. For example, to log to the Testing.log file, specify "Testing".
The file must be located in the default log directory. You cannot specify a directory path. If the file does not exist, it is created automatically, with the extension .log.
(My emphasis).
Reading the docs is always a good place to start when wondering how things might work.
So <cflog> will only log to the ColdFusion logs directory, and that is by design.
I don't have CF8 handy, but you would be able to set the logging directory to be a different one via either the CFAdmin UI (CF9 has this, I just confirmed), or neo-logging.xml in WEB-INF/cfusion/lib.
Or you could use a different logging mechanism. I doubt it will work on a rusty of CF8 install, but perhaps LogBox?
pConnect->SetCurrentDirectory( "C:\\FilesToSendToServer" ); //Need this set on client, i believe currently setting on server.
CFtpFileFind finder(pConnect);
finder.FindFile( "*", INTERNET_FLAG_DONT_CACHE | INTERNET_FLAG_EXISTING_CONNECT );
finder.FindNextFile();
CString filename = finder.GetFileName(); //finds the only file in that directory - test.txt
pConnect->PutFile( filename, "C:\\FilesReceived\\FILE_SENT_FROM_CLIENT.txt", FTP_TRANSFER_TYPE_BINARY, 1 )) //filename set to test.txt correctly
On the client I have the directory FilesToSendToServer with one test file - "test.txt"
I also have the working directory of this application on the client - C\uploadApp\
The code above sets the current directory correctly and "finds" the test file.
However, when PutFile executes with the filename parameter set correctly (test.txt) the functin returns the error file not found.
So as a test, I put a copy of test.txt in the applications working directory uploadApp and it DID send the file to the server.
Why does the file need to be in the working directory to be sent if the active directory is set in the CFtpConnection object?
(Does this mean for any file I want to send from the client I have to copy it over to the directory of the application?)
Thank You.
EDIT
Looks like SetCurrentDirectory calls FtpSetCurrentDirectory which
determine the remote site's current working directory
So for a GET this would make sense...is there an alternate function for a PUT - to set the active directory of the local machine? (FYI - Unable to make a distinction between the remote directory on the server testing on same machine...if testing on target the SetCurrentDirectory should fail, as it is looking on the server...I assume)
It looks like you were meaning to call the win32 API SetCurrentDirectory. This will change the local directory instead of the remote directory that pConnect->SetCurrentDirectory changes. Try ::SetCurrentDirectory if you're in a namespace. Of course your working directory will no longer be C:\uploadApp...
To change the working directory on the client side you should be able to call Win32 ::SetCurrentDirectory.
You will find it easier to get this code working if you get in the habit of checking for errors on any Win32 call, including those encapsulated within MFC.