I am trying to access information under C:\Users\Public\Documents\ which displays as C:\Users\Public\Public Documents\ on explorer. Is there a way to be able to access the DirectoryInfo of a directory under the junction using the pathname displayed in explorer in .NET C#?
When/how are you expecting to get a C:\users\public\public documents path?
If a user goes to copy/paste from Explorer, the C:\users\public\documents path will be copied into the clipboard. Going through a SaveFileDialog also produces the valid path.
If you need a way to access Windows 7 libraries, you can give the Windows API Code Pack a go. You can then access "Public Documents as KnownFolders.PublicDocuments, for example. From what I can see (I've never used it before), there's still no way to reliably turn C:\users\public\public documents into a DirectoryInfo, but you might have better luck digging through the docs.
Related
I want to transfer a file to an Android device using a USB cable and file explorer, and then access it in my Xamarin.Forms app.
As far as I understand there are two ways to do this (and please correct me if I'm wrong):
Since it's an image file - Just put it anywhere and let some
background task find it and add it to what seems to be a virtual
folder of Images. And then access it there.
A more general solution - browse to that specific folder.
Both solutions rely on using FileInfos etc. but unfortunately the folder structure is much different than I see using windows explorer - instead of Alarms, Android, etc. which I see on windows explorer - is see cache, config, etc. using C#, and access to some like data is not allowed (I get an exception). I also tried finding information on how I would search for all images on the device, but either it's not as simple as I thought it would be, or I'm using the wrong keywords.
The file will be put there by a user, so it cannot be added to the project's resources.
Xamarin has a nice way to navigate the files in android, using Android.OS.Environment.ExternalStorageDirectory.Pathwhich you can concatenate with your directory/filename so you can save/access data.
If you want to open the android dialog box so the user can find a file in its device, you can take a look at: https://developer.xamarin.com/recipes/android/data/files/selecting_a_gallery_image/
Remembering that you need to add the READ_EXTERNAL_STORAGE permission to your android manifest file and check runtime permissions. Runtime permissions can be easily checked with https://github.com/jamesmontemagno/PermissionsPlugin
I've been trying to learn how to handle saving normal .txt files in UWP, and have realized that it's quite locked down compared to WPF, especially in the sense of what folders you can access without requesting the user to select a location. I have searched for various ways this might be possible but found no working answer.
Question Description:
I basically would love to know if this is possible, and preferably a point in the direction where I can learn how exactly to do this.
Application settings page requires user to select folder where files are saved.
Application remembers this between launches (unsure if this is possible, but I can't require the user to select the folder on every launch)
Application saves files to the specified folder.
In my understanding, this should be possible, as the user is the one specifying the location via filepicker, but is it possible to have this work between launches so that the user wont be required to re-select the save folder?
I need to figure this out, as I would like my application to support selecting attached network drives, cloud storage folders, etc.
Any help is very much appreciated, and if there are any questions I will answer them to the best of my ability.
Fow this purpose there are two access lists designed: FutureAccessList and MostRecentlyUsedList. Once the user has picked up the folder with the picker, you add it to such list and receive a token, which you save for future purpose in LocalSettings:
ApplicationData.Current.LocalSettings.Values["MyFolder"] = StorageApplicationPermissions.FutureAccessList.Add(pickedFolder);
Then later, once you want to access that folder, you can do it like this:
StorageFolder folder = await StorageApplicationPermissions.FutureAccessList.GetFolderAsync(ApplicationData.Current.LocalSettings.Values["MyFolder"].ToString());
You can't save a StorageFolder or a path to it in settings, hence the UWP app needs permissions to access the folder. Using above access lists solves this problem.
I believe you want to save user settings and keep it somewhere so that next time when they launch the application, they can use the same settings.
Please check out this tutorial from Microsoft, which describes how to do exactly that.
https://msdn.microsoft.com/en-us/library/bb397750(v=vs.110).aspx
I am currently attempting to read in files (that the user selects) and store them (with their permission). The trouble I am having is that, having SkyDrive installed and enabled, I have what are known as SMART files, noted with a LocallyIncomplete attribute.
What this means is that the SkyDrive app stores a reference to this file in SkyDrive, but does not actually pull the whole file until the user requests it (by using it in some way). This works totally fine if they access the file in the picker via the SkyDrive app (the drop down at the top left). It even marks those that are not completely offline as LocallyIncomplete while not marking those that are available offline.
The issue (that I was lucky enough to find) is that I have included a folder in my SkyDrive app inside of a library (specifically, my Documents library). This makes all of the files show up in the picker, as it should.
If I try and open any SkyDrive files from the library, then not only does it mark all of them as LocallyIncomplete (even when the SkyDrive app does not), but it throws a native IOException, which is impossible for my app to catch. This happens even if the file being requested is locally available through the SkyDrive App. This is consistently reproducible on my machine.
Upon further investigation, it seems that I can check the Provider property to make sure that files with the LocallyIncomplete attribute come from the SkyDrive app, which is good at least (in that I can avoid an uncatchable exception). This will work for now as a Workaround, but it's less than ideal.
Also, I haven't been able to find any mention of this on Connect/MSDN. I'm hoping a MSFT-y wouldn't mind double checking to see if there's a bug filed for this before I file one myself, as I haven't been able to find one.
Thanks.
LocallyIncomplete means the file is not 100% downloaded to the user's machine.
You can check this way
if (!file.Attributes.HasFlag(FileAttributes.LocallyIncomplete))
{
//dostuff
}
where file is of type StorageFile
Windows defines five folder types (general items, documents, pictures, music, and video). In Windows Explorer you can get/set the type by right-clicking on the folder and selecting Properties->Customize->Optimize this folder for. I'm looking for a way to get/set folder type in C#. I've searched for this, but I must not be using the correct terminology.
Can someone point me in the right direction?
Update: Thanks to all for the insights! Thought this would be simple - apparently NOT.
Very odd. I can select a folder with no desktop.ini. I can change the properties of that folder, select a folder type, click apply, see a desktop.ini is created, and see the folder view change accordingly. However, I can delete desktop.ini and the folder type persists. Through Explorer restart. Through Windows restart.
With regard to possible shadow copies, I can find no evidence to support this. Except for C:, system protection is turned off on all my drives. Using ShadowExplorer, I find no references to any desktop.ini files.
Puzzling...
I think you can either use a desktop ini file or the registry.
However, if you create a desktop.ini in a folder be sure to add the "System" attribute to that folder, otherwise the desktop.ini will be ignored.
attrib +s FolderName
(or with C# Code)
Link to MSDN http://msdn.microsoft.com/en-us/library/aa969337.aspx
Folder type is stored in desktop.ini file located in that folder (which has SYSTEM attribute and its not visible by default - you have to uncheck "Hide protected system files in Windows Explorer settings).
Example desktop.ini content from Windows 7 from folder set to "optimize for pictures" or whatever its called in english Windows.
[ViewState]
Mode=
Vid=
FolderType=Pictures
To change/read FolderType you can just change/read that file.
That file (desktop.ini) can contain more settings (like custom icon file/resource location). See desktop.ini in standard Documents or Desktop folder.
Edit/update according to comment:
Maybe that happends, because files with system attribute may have shadow copy and they will be restored after you delete them? I'm sure that there is no other place where this is stored.
Try to overwrite that file instead of deleting.
In Windows Registry there are only default settings applied when you create new folders.
Also I made some more digging, and found some information about WINAPI function that handles desktop.ini files "more properly".
See this:
Create Icons for Folders in Windows Explorer, Using C# by Evan Stone at codeproject.net
One more thing about customized folders without desktop.ini - I think this is impossible. Check that again and make sure, that you can see files with system attribute.
Edit 2:
Please take a look at SchlaWiener answer, he pointed at something important.
I downvoted his answer, but I was wrong, now I cant undo my vote.
Well, you want a direction, so.....
This is a link to a Microsoft document about the customization for folders...
How to modify your folder view settings or to customize a folder
In this article you will find a reference to a couple of Registry Subkeys and Keys.
Of course they are not the same in different Windows version (too easy)
WinXP, 2003
HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell
HKEY_CURRENT_USER\Software\Microsoft\Windows\ShellNoRoam
Vista, Win7
HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell
Looking at the mentioned registry Keys and at the complexity behind these keys I really suggest to leave this work to the OS itself.
EDIT I have been hit in my self esteem by some rude comments below, so I have decided to search for a bit more documentation on this DESKTOP.INI file that seems to be a better option to solve your problem. I have found this documentation that seems to be very exaustive (but again it also demonstrates how handling correctly this little file is very complex) And by the way I have still to understand if just changing this file really makes a difference or not. As far as I have tried the test folder remains unchanged but this could be caused by some sort of caching.
I would like to know how Windows generate folder, where will be ClickOnce application installed.
In Startmenu is "shortcut" to file, what is putted in some "startrek" folder like:
C:\Users\USERNAME\AppData\Local\Apps\2.0\GT??4KXX.PRJ\EGV???1G.??C\prin..tion_7???5a2?????74b6_0000.0002_1dae????89111c35
What does those folder names mean?
For example:
If i will have for example some settings.txt file where i want that user can change some parameters of the application. Is there way how to know, WHERE it will be installed and WHERE the file is? (Where user will find this settings.txt file).
I know that i can create the file for example in C:\ and after start the application i will modify the file in "strong" path. But i dont really like too much files, folders, whatever in C:\ and i prefer to have settings files in same folder like the application. But with ClickOnce installations is it really hard - impossible - to find that file.
It seems like when the "startrek" is something like hash of the project.
So i would like to know what does the folder means and if its some hash of the project or what is that.
To find the folder that contains your executable, you can use the Assembly.Location property.
For example:
string exeFolder = System.Reflection.Assembly.GetExecutingAssembly().Location;
However, if you want to store settings for your ClickOnce app, you shouldn't do it by writing a file to the .exe's folder.
Instead, you should use Microsoft's Application Settings support. Doing it any other way is going to be a lot of extra hassle, and Microsoft's support is very good. It does need half an hour to read through the documentation, but it's far and away the best thing to do, IMHO.
(I'm assuming that you only need the settings to be stored on the local PC for the same user to use later. If you want the settings to follow the user around (i.e. roaming settings), you can't use the Microsoft support.)
If you have more complex settings that you want to store in a file that you create directly, you should consider using the isolated storage that the answer from JRoughan mentions.
From inside the ClickOnce app you can find the default directory where files are stored using
ApplicationDeployment.CurrentDeployment.DataDirectory
Or you can use isolated storage and choose whether you want to save per application or per user.
I don't think it's possible to determine these folders from outside the app itself. If you need a known location you'll have to hard-code it.
Update
I also don't believe it's possible to infer what the install directory will be for an app. It would be unwise to use even if possible as updates to the app will not be in the same location.
If you have data that the user is modifying through your program, you will be happier if you don't leave it in the ClickOnce program directory. You can get completely messed up when there's an update. Check out this article about what to do with your data to keep it safe and be able to find it. It talks about putting it in LocalApplicationData, but if you want your user to be able to find it and edit it, just put it in MyDocuments/yourappname/settings or something like that.
I wouldn't use Isolated Storage; there are reported problems with that and ClickOnce.