When I want to write a file to the internal storage/Documents, I don't see any file that was created.
Also the path that it returns looks a bit weird.
"/data/user/0/com.companyname.writeexternaldocs/files/temp.txt"
Because I'm working on Android v10/api29 I have to use the mediastore
string fileName = Path.Combine(System.Environment.GetFolderPath(System.Environment.SpecialFolder.MyDocuments), "temp.txt");
File.WriteAllText(fileName, "Some text?");
bool doesExist = File.Exists(fileName);
But when I look at this folder on my android device the temp file is not there. Can anybody point me to the right direction?
Thanks in advance
Related
From research I have found that it is possible to determine the available space for storing app files on iOS, Android and UWP using dependency services with the Platform specific code below:
For iOS:
private double GetRemainingStorageSpace(string directoryPath)
{
var freeExternalStorage = NSFileManager.DefaultManager.GetFileSystemAttributes(directoryPath).FreeSize;
return (double)freeExternalStorage;
}
For Android it can be done like:
var path = new StatFs(directoryPath);
long blockSize = path.BlockSizeLong;
long avaliableBlocks = path.AvailableBlocksLong;
double freeSpace = blockSize * avaliableBlocks;
return freeSpace
or like this:
var fl = new Java.IO.File(directoryPath);
var freeSpace = fl.UsableSpace;
return (double)freeSpace;
For UWP:
string freeSpaceKey = "System.FreeSpace";
StorageFolder folder = await StorageFolder.GetFolderFromPathAsync(directoryPath);
var properties = await folder.Properties.RetrievePropertiesAsync(new string[]
{
freeSpaceKey
});
var freeSpace = properties[freeSpaceKey];
return (UInt64)freeSpace;
My question then is:
1.) Do these lines of code above actually return the amount of bytes that can be stored in a specific directory? Or do they return the amount of bytes that can be stored on the whole device?
2.) For Android I am not too sure what the difference between the two ways of doing this are I am hoping for an explanation of the difference between the both of then and which is a better to use?
Would appreciate an explanation.
1.) Do these lines of code above actually return the amount of bytes that can be stored in a specific directory? Or do they return the amount of bytes that can be stored on the whole device?
Obviously it is specific directory ,because in the code it needs specific folder path as parameter .
You can try to set directoryPath as
System.Environment.GetFolderPath(System.Environment.SpecialFolder.MyDocuments)
and
System.Environment.GetFolderPath(System.Environment.SpecialFolder.Personal)
to see the difference.
2.) For Android I am not too sure what the difference between the two ways of doing this are I am hoping for an explanation of the difference between the both of then and which is a better to use?
I can't tell the difference or which is better, because based on my test the result comes the same , and for details you can refer to here , it's maybe helpful .
I am trying to identify when a file is PNG or JPG to apply it as a wallpaper. I am using the SHGetFileInfo to get the type name with the .szTypeName variable, but I just realized that it changes if the OS is in another language.
This is my code:
SHFILEINFOW fileInfo;
UINT sizeFile = sizeof(fileInfo);
UINT Flags = SHGFI_TYPENAME | SHGFI_USEFILEATTRIBUTES;
// Getting file info to find out if it has JPG or PNG format
SHGetFileInfoW(argv[1], 0, &fileInfo, sizeFile, Flags);
This is how I am validating:
if (wcscmp(fileInfo.szTypeName, L"JPG File") == 0)
{
//Code here
}
When the OS is in spanish, the value changes to "Archivo JPG" so I would have to validate against all language, and does not make sense.
Any idea what other function I can use?
This API is meant to be used to produce a user-facing string representation for known file types1). It is not meant to be used to implement code logic.
More importantly, it doesn't try to parse the file contents. It works off of the file extension alone. If you rename an Excel workbook MySpreadsheet.xlsx to MySpreadsheet.png, it will happily report, that this is a "PNG File".
The solution to your problem is simple: You don't have to do anything, other than filtering on the file extension. Use PathFindExtension (or PathCchFindExtension for Windows 8 and above) to get the file extension from a fully qualified path name.
This can fail, in case the user appended the wrong file extension. Arguably, this isn't something your application should fix, though.
As an aside, you pass SHGFI_USEFILEATTRIBUTES to SHGetFileInfoW but decided to not pass any file attributes (second argument) to the call. This is a bug. See What does SHGFI_USEFILEATTRIBUTES mean? for details.
1) It is the moral equivalent of SHGFI_DISPLAYNAME. The only thing you can do with display names is display them.
I have a folder with a number of .wav files inside. I need to dynamically count these files in order to generate the sound in a random way. I need this dynamically, so I don't need to update code everytime I update the sound folder with another sound.
I searched how to do it, but could only found examples for Windows. Here's the code I came up with:
string path = string.Format("/Sound/{0}", sourceSound);
return Directory.GetFiles(path, ".wav").Length;
I tried running it, but VS gives me the error:
"Unable to step. The code is currently unavailable."
Is there anything I'm doing wrong, or any other case how can we count the number of files inside a folder?
Thanks.
Try
using (var myIsolatedStorage = IsolatedStorageFile.GetUserStoreForApplication())
{
var i = myIsolatedStorage.GetFileNames("*.wav").Length;
}
For some reason I couldn't make the example Vitalii gave me work. I was never able to get the count of files I have in the volder.
Looking over the internet, I stumbled upon this link:
confused about resources and GetManifestResourceNames()
The answer Zack gave on this thread, gave the insight I needed to make my App work.
I used Embedded Resource to find all the count of files I needed and, then, play the with a SoundEffectInstance.
The following link helped on this:
http://matthiasshapiro.com/2011/01/10/embedding-a-sound-file-in-windows-phone-7-app-silverlight/
Here's how I managed to make it work:
soundCount = GetSoundCount();
private int GetSoundCount()
{
return Assembly.GetExecutingAssembly().GetManifestResourceNames().Where(name => name.Contains(sourceImg)).Count();
}
With these few lines I managed to get the exact number of files I have in my App.
To make the sound play, I used the second link as an example and produced the code below:
if(soundInstance != null)
soundInstance.Stop();
this.soundInstance = SetNextSource();
soundInstance.Play();
private SoundEffectInstance SetNextSource()
{
Random random = new Random();
Assembly assembly = System.Reflection.Assembly.GetExecutingAssembly();
Stream stream = assembly.GetManifestResourceStream(string.Format("Assembly Name.Folder.{0}.{1}.wav", SubFolder, FileName + random.Next(soundCount)));
SoundEffect se = SoundEffect.FromStream(stream);
return se.CreateInstance();
}
Well after a few days o research finally managed to make it work.
Hope this thread helps people facing the same problem I did.
Thanks.
Is there any way to know about the user who has checked in last items on VSS?
We've shared folder on our server(other than VSS server) where we keep internal project copies. But recently someone has replaced it with some invalid copy. As there isn;t any way of finding who has done this job, I looked for some trace of information that may help in finding the user who has done this; and I found VSS control meta data file in project folder?
It has following piece of information:
""
{
"FILE_VERSION" = "9237"
"ENLISTMENT_CHOICE" = "NEVER"
"PROJECT_FILE_RELATIVE_PATH" = ""
"NUMBER_OF_EXCLUDED_FILES" = "0"
"ORIGINAL_PROJECT_FILE_PATH" = ""
"NUMBER_OF_NESTED_PROJECTS" = "0"
"SOURCE_CONTROL_SETTINGS_PROVIDER" = "PROVIDER"
}
Is this of any help for tracing out the same version on VSS?
thanks in advance,
Kapil
Or look into the journal.txt in your vss database folder
What's the way to get default volume on Mac 64-bit?
I have a code like that:
GetVolParmsInfoBuffer buf_64 = { 0 };
status = FSGetVolumeParms(vol_ref, // use default volume
&buf_64, // write
req_count);
The problem is that I can't pass 0 in vol_ref. On Mac 32-bit I could write:
GetVolParmsInfoBuffer buf_32 = { 0 };
HParamBlockRec pb;
pb.ioParam.ioCompletion = NULL; // not doing async I/O
pb.ioParam.ioNamePtr = NULL; // we don't use path name
pb.ioParam.ioVRefNum = 0; // use default volume
pb.ioParam.ioBuffer = reinterpret_cast(&buf_32); // write data here
pb.ioParam.ioReqCount = req_count;
OSErr err = PBHGetVolParmsSync(&pb);
ASSERT_EQ(err, noErr);
Thanks in advance,
- Oleksii
In the File Manager docs, you'll notice a function group titled “Manipulating the Default Volume”. All of those functions are deprecated.
If you search Google for the functions therein, particularly HSetVol, you'll find this mailing list post by Eric Schlegel, which says HSetVol had the effect of setting the current working directory (expressed as a volume/directory pair) on Mac OS. He also says that it doesn't work on Mac OS X: It should work on File Manager functions, but does not set the working directory used for resolving relative paths in other APIs (e.g., open and fopen) like it did on Mac OS.
Moreover, those functions are not available in 64-bit Mac OS X. So the answer is: You don't, because there is no default volume.
The old meaning of it was analogous to the current working directory, so you can do the same thing by getting the CWD and resolving that path to an FSRef. However, for a Mac OS X application (particularly one that doesn't set the CWD by any means, as most don't), this is not terribly useful: The default CWD for an application is /, the root directory of the boot volume. On the other hand, if you run your executable directly or under Xcode's Debugger, its CWD will not be /, which means it could be some other volume—most probably, the one with your Home folder on it.
You should refer to the boot volume (or whatever volume you're interested in) specifically, not attempt to get or simulate getting the default (current working) directory.
For the boot volume, you might try kOnSystemDisk, which is one of the constants in the Folder Manager. If that doesn't work, use Folder Manager's FSFindFolder function to retrieve the System folder, then use File Manager's FSGetVolumeInfo function to get what volume it's on.
Well. I don't really know what "default volume" is. All I know is that Carbon manual (File Manager) says:
ioVRefNum
A volume reference number, 0 for the default volume, or a drive number.
Well, I seem to find the answer for my question.
FSVolumeInfoParam vol_info = { 0 };
vol_info.ioVRefNum = kFSInvalidVolumeRefNum; // will obtain it
vol_info.volumeIndex = 1; // XXX: is it the default volume as well?
vol_info.whichInfo = kFSVolInfoNone; // don't pass volume info
err = PBGetVolumeInfoSync(&vol_info);
The only thing I'm not sure of is if the 1st volume is the default one...
P.S. I guess the problem is that I don't quite understand what "default volume" really is ;-)