The Difference Of Location Storage File in air - file-io

I want to ask the difference between air.File.documentsDirectory.resolvePath, File.userDirectory.resolvePath, air.File.applicationDirectory.resolvePath..
Can anybody explain when does the file will be store.....
especially in windows

AIR's applicationStorageDirectory will automatically target these locations depending on which OS the application is running:
Windows 7 / Vista: c:\users\USERNAME\appdata\roaming\APPLICATIONNAME
Windows XP: c:\Documents and Settings\USERNAME\Application
Data\APPLICATIONNAME
Mac OS X: /Users/USERNAME/Library/Preferences/APPLICATIONNAME
Linux (Ubuntu): /Users/USERNAME/.appdata/
along with desktopDirectory, documentsDirectory, applicationDirectory (read-only), which, too, have their own specific locations, these are built-in conveniences that allow AIR developers to produce cross-platform applications without having to know about (or specifically code for) the file system of a target OS.

This info applies to AIR 1.0 and later (ActionScript 3.0)
File.applicationStorageDirectory: a storage directory unique to each installed AIR application. This directory is an appropriate place to store dynamic application assets and user preferences. Consider storing large amounts of data elsewhere. On Android and iOS, the application storage directory is removed when the application is uninstalled or the user chooses to clear application data, but this is not the case on other platforms.
File.applicationDirectory: the directory where the application is installed (along with any installed assets). On some operating systems, the application is stored in a single package file rather than a physical directory. In this case, the contents may not be accessible using the native path. The application directory is read-only.
File.desktopDirectory: the user’s desktop directory. If a platform does not define a desktop directory, another location on the file system is used.
File.documentsDirectory: the user’s documents directory. If a platform does not define a documents directory, another location on the file system is used.
File.userDirectory: the user directory. If a platform does not define a user directory, another location on the file system is used.
If you specify a publisher ID in the AIR application descriptor, then the publisher ID is appended to the applicationID.
Android
File.applicationDirectory (read-only)
/data/data/
File.applicationStorageDirectory
/data/data/<applicationID>/<filename>/Local Store
File.cacheDirectory
/data/data/<applicationID>/cache
File.desktopDirectory
/mnt/sdcard
File.documentsDirectory
/mnt/sdcard
temporary - from File.createTempDirectory() and File.createTempFile()
/data/data/<applicationID>/cache/FlashTmp.<randomString>
File.userDirectory
/mnt/sdcard
iOS
File.applicationDirectory (read-only)
/var/mobile/Applications/<uid>/<filename>.app
File.applicationStorageDirectory
/var/mobile/Applications/<uid>/Library/Application Support/<applicationID>/Local Store
File.cacheDirectory
/var/mobile/Applications/<uid>/Library/Caches
File.desktopDirectory - not accessible
File.documentsDirectory
/var/mobile/Applications/<uid>/Documents
temporary - from createTempDirectory() and createTempFile()
/private/var/mobile/Applications/<uid>/tmp/FlashTmp<randomString>
File.userDirectory - not accessible
Linux
File.applicationDirectory (read-only)
/opt/<filename>/share
File.applicationStorageDirectory
/home/<userName>/.appdata/<applicationID>/Local Store
File.desktopDirectory
/home/<userName>/Desktop
File.documentsDirectory
/home/<userName>/Documents
temporary - from createTempDirectory() and createTempFile()
/tmp/FlashTmp.<randomString>
File.userDirectory
/home/<userName>
Mac
File.applicationDirectory (read-only)
/Applications/<filename>.app/Contents/Resources
File.applicationStorageDirectory (AIR 3.2 and earlier)
/Users/<userName>/Library/Preferences/<applicationID>/Local Store
File.applicationStorageDirectory (AIR 3.3 and later)
/Users/<userName>/Library/Application Support/<applicationID>/Local Store
File.applicationStorageDirectory (AIR 3.3 and later) sandboxed
/Users/<userName>/Library/Containers/<bundleID>/Data/Library/Application Support/<applicationID>/Local Store
File.cacheDirectory
/Users/<userName>/Library/Caches
File.desktopDirectory
/Users/<userName>/Desktop
File.documentsDirectory
/Users/<userName>/Documents
temporary - from createTempDirectory() and createTempFile()
/private/var/folders/<userName?>/<randomString>/TemporaryItems/FlashTmp
File.userDirectory
/Users/<userName>
Windows
File.applicationDirectory (read-only)
C:\Program Files\<filename>
File.applicationStorageDirectory
C:\Documents and settings\<userName>\ApplicationData\<applicationID>\Local Store
File.cacheDirectory
C:\Documents and settings\<userName>\Local Settings\Temp
File.desktopDirectory
C:\Documents and settings\<userName>\Desktop
File.documentsDirectory
C:\Documents and Settings\<userName>\My Documents
temporary - from createTempDirectory() and createTempFile()
C:\Documents and Settings\<userName>\Local Settings\Temp\<randomString>.tmp
File.userDirectory
C:\Documents and Settings\<userName>
Source

Copying from Victor's comment: In later versions of OS X, applicationStorageDirectory will be in /Users/USERNAME/Library/Application Support/APPLICATIONNAME
This is the correct location in MAC OS in 2016

In addition to TheDarkini1978's answer:
File.applicationDirectory is read only, don't try to save files there. resolvePath function creates file object with name relative to given file. When in doubt, always see the docs: File

Related

Folder.CopyHere() from IShellDispatch silently fails to unpack most of a Zip file, but only if the file is on a DVD

My application (the Endless OS installer for Windows) uses methods on IShellDispatch (provided by Shell32.dll), to extract a Zip file (example). In various modes of operation, this file may be downloaded from the internet to a fixed disk; on an exFAT filesystem on a USB stick; or in an ISO 9660 (with Joliet extensions) image which may be mounted as a virtual drive, or written to a DVD. In all cases but the last, extracting the Zip file works; but when the Zip file is on a DVD, all that's created in the target directory is the directory structure (EFI\BOOT\) for the first file in the archive (EFI\BOOT\bootx64.efi); neither that file, nor any other files in that directory or any other directory, are extracted. With exactly the same Zip file on any other medium — including inserting the ISO into a VirtualBox virtual optical drive — the problem disappears.
The original C++ code where I first saw this problem is here. It looks like this (with error handling removed, since all methods return a successful HRESULT in my testing, and the FOF_NO_UI also removed in case that was masking an error message):
void UnpackZip(const CComBSTR source, const CComBSTR dest) {
CComPtr<IShellDispatch> pISD;
CComPtr<Folder> pToFolder, pFromFolder;
CComPtr<FolderItems> folderItems;
CoCreateInstance(CLSID_Shell, NULL, CLSCTX_INPROC_SERVER, IID_IShellDispatch,
(void **)&pISD);
pISD->NameSpace(CComVariant(dest), &pToFolder);
pISD->NameSpace(CComVariant(source), &pFromFolder);
pFromFolder->Items(&folderItems);
pToFolder->CopyHere(CComVariant(folderItems), CComVariant(0));
}
I can reproduce this problem both by attempting to unpack the Zip file from Windows Explorer GUI (which does not report any errors), and by running the following in PowerShell, so I am reasonably sure it's not my application code that's at fault:
PS> $shell = new-object -ComObject shell.application
PS> $zip = $shell.NameSpace("D:\endless\eos-eos3.3-amd64-amd64.171122-232702.base.boot.zip")
PS> $target = $shell.NameSpace("C:\test")
PS> $target.CopyHere($zip.items())
If I explicitly iterate over the top-level folders in the Zip file, as follows, then some but not all files from each folder are extracted (and still none in EFI\BOOT\):
PS> foreach ($item in $zip.items()) { $target.CopyHere($item) }
If I explicitly select that first file which is not unpacked, no error is raised:
PS> $item = $zip.items().Item(0).GetFolder().Items().Item(0).GetFolder().Items().item(0);
PS> $item
Application : System.__ComObject
Parent : System.__ComObject
Name : bootx64.efi
Path :
GetLink :
GetFolder :
IsLink : False
IsFolder : False
IsFileSystem : False
IsBrowsable : False
ModifyDate : 22/11/2017 23:33:56
Size : 1157984
Type : EFI File
PS> $target.CopyHere($item)
But it's still not unpacked to $target. The DVD drive does not even spin up!
If I copy exactly the same Zip file to a fixed drive – or mount the DVD ISO as a virtual disk, whether within Windows, or from the outside via the VirtualBox VM Windows is running in – everything works correctly. The problem only occurs when the archive is really on a physical DVD. I've received many reports of this problem from users with various hardware, so it's not my DVD drive or laptop. I personally have only tested and reproduced it on Windows 10 (build 14393 and 15063, at least); I'm not sure whether it can be reproduced on older Windows versions but since Windows 10 is the most commonly-used version by users of this application, it's a moot point whether this worked on older versions.
The files which are not unpacked are all those ending .efi (EFI executables) and those ending .mod (legacy BIOS GRUB modules). This is totally deterministic. But I'm stumped as to why the shell would take such a disliking to certain files, only when the archive is on a DVD.
My application can work around this problem by copying the Zip file to the hard disk before extracting it. But the question remains: why is this happening? And at a higher level: short of stepping through the compiled Shell32.dll code in a debugger, how could I diagnose what's going wrong?

Accessing USB drive form WinPE prompt

I am trying to install Windows 8 on virtual box using a bootable WinPE DVD. The image file (.wim) is on the USB stick.
But when I boot from DVD, I cannot find the USB drive.
I need to execute the command
d:\imagex.exe /apply e:\imageC_20150528.wim 1 c:\
where D - dvd drive and say E - usb drive
But I cannot locate the USB drive from the command prompt.
When I use winPE I use DiskPart to determine the drive letter of the USB drive.
-Diskpart
-list volume
This should display all available drives
If the USB drive was inserted before you booted the system into PE, then the USB drive should already be mounted and have a drive letter. If it doesn't then it is likely the drive isn't supported (you might want to change your boot-image/disk to include additional drivers/tools to get access to your usb controller and connected device).
If your USB drive was inserted after you booted the system into PE (and your hardware is supported in PE) then I usually can access the disk in the following manner (worked even in XP PE):
go to commandline and start diskpart (following commands are in diskpart):
issue command: rescan enter
This 'Locates new disks that might have been added to the computer.'
Depending on diskpart version (and/or it's automount setting) this can be enough to automatically mount the file system for a new basic volume when it adds the drive to the system and assigns a drive letter to the volume.
When it doesn't, follow the following 2 steps:
command: list disk enter
to see a list of disks and some info (to check the drive was found)
command: list volume enter
lists volumes on all disks (to find volume number of the USB drive)
command: select volume=# enter (where #= volume number)
to select the specified volume and shift the focus to it
command: assign enter
to assign the next free letter to the current focused volume
OR: assign letter=# enter (where #= driveletter of choice)
This method usually works for me on most hardware.
See also: Diskpart commandline options on MS Technet
Really - you should be using a fairly current version of winPE - 5.1 is what I'm using - which is the version that parallels windows 8.1. I'm switching over to winPE 10 (they changed the numbering to be consistent with Windows)
The reason I bring this us is because you're using imagex - and dism.exe has largely replaced imagex.exe in more current versions of winPE.
If you're just doing this at the command prompt in a generic winPE, you can use mountvol.exe (with no parameters) to discover the drive letters that are available. Everything shifts around drive-letter-wise when you're in winPE. So it might not be e: any more.
Also, dism and/or imagex would be on the x: drive - which is the virtual drive that the winPE creates when it boots.

Windows Mobile Compact Framework Build Error: CAB file … could not be created

I get the following error when trying to build a .CAB in visual studio on my new PC. The source is identical. The Registry warnings are not present on the old PC either.
Windows CE CAB Wizard
Warning: Section [RegKeys] has no data
Warning: Section [DefaultInstall] key "AddReg" - there are no section entries to process
Error: CAB file "D:\Dev\...\MyProject.CAB" could not be created
ERROR: The Windows CE CAB Wizard encountered an error. See the output window for more information.
No other errors show in the build log for the cabwiz.exe build step.
Any suggestions?
Move the source code to C: drive and build it there, instead of D: drive.
It appears that when cabwiz.exe (Visual Studio) is installed on C: drive, it does not like building projects on D: drive.
Similar issues with network drives noted at http://windowsmobilepro.blogspot.co.uk/2005/11/error-cab-file-could-not-be-created-no.html
Finally I found an answer. All my problems comes from the 8.3 file name generation.
You have to check two thing.
Registry key NtfsDisable8dot3NameCreation under
HKLM/SYSTEM/CurrentControlSet/Control/FileSystem
Valid values are:
0 - Disable 8.3 name generation
1 - Enable 8.3 name generation
2 - Name generation will be evaulated by volume settings
Matty Brown suggested the following (not tested, but may help):
Valid values are (Windows 10 1809):
0 - Enable 8dot3 name creation on all volumes on the system
1 - Disable 8dot3 name creation on all volumes on the system
2 - Set 8dot3 name creation on a per volume basis
3 - Disable 8dot3 name creation on all volumes except the system volume
Volume based settings.
You need an admin command prompt. Check 8.3 name generation with
fsutil 8dot3name query d:
where "d:" is your volume
If the result inform you that your volume has disabled 8.3 name generation, you can set it easily with
fsutil 8dot3name set d:
Two more step is needed. You need a restart, and you have to move files from there and move it back to the original place.
The 8.3 name generation linked to the file operations.
Thats all.
I'm happy now with my new W10 ultrabook with VS2008 and a big WinCe 6 solution.
I know it's a bit too late, but I'll leave this tip for future visits:
Check for whitespaces in Solution & CAB project paths, and also in file names.
I ran into this error while trying to build a legacy CAB project on our new TFS Build Server running Windows 2012. Ironically, the script to build the mobile app and CAB project worked fine on my local development machine, but go the vague "Windows CE CAB Wizard Error: CAB file XXXXXX could not be created" error when I ran it on the build server, via both a TFS build definition or manually.
The article previously mentioned at http://windowsmobilepro.blogspot.co.uk/2005/11/error-cab-file-could-not-be-created-no.html was very thorough and helpful. I used the SUBST trick to shorten the project path and eliminate the spaces in the path names, and the script could then run on TFS / Win2012.

Deploying ClickOne application with network share

We have a server PC and other client PCs working connected to server using LAN. We have a application for our internal use which is developed using VB.Net. I used steps in http://www.codeproject.com/Articles/17003/ClickOnce-Quick-steps-to-Deploy-Install-and-Update to deploy clickone statergy for updating our application.After publishing while installing application,this error is coming
I searched i details and found this error
ERROR SUMMARY
Below is a summary of the errors, details of these errors are listed later in the log.
* Activation of D:\Desktop\publish\Global.application resulted in exception. Following failure messages were detected:
+ Downloading file:///D:/Desktop/publish/Application Files/Global_1_0_0_0/Global.XmlSerializers.dll.deploy did not succeed.
+ Could not find file 'D:\Desktop\publish\Application Files\Global_1_0_0_0\Global.XmlSerializers.dll.deploy'.
+ Could not find file 'D:\Desktop\publish\Application Files\Global_1_0_0_0\Global.XmlSerializers.dll.deploy'.
+ Could not find file 'D:\Desktop\publish\Application Files\Global_1_0_0_0\Global.XmlSerializers.dll.deploy'.
I have checked Application files in publish options and Global.XmlSerializers.dll is included. Anyone know why this is happening?
Is there any way to copy some extra files to installation folder(C:\Users\name\AppData\Local\Apps..) when installing or updating clickone application? Because we use some outside support files for our application. Is it possible?
Is there any way to pass argument to clickone application short cut,like passing argument to .exe shortcut("\Global.exe" ?/?customer?/?)?
EDIT:
This is how I published
I checked by giving network path for publishing folder location.But same error coming.
Here is application files included
As you can see Global.XmlSerializers.dll is included
It is looking for a file on the D: drive. It is unlikely that your users all have their D drive mapped to the same location. When you publish you should use the full path rather than mapped drive letters.
//Servername/shareddirectory/appdirectory
Does the install work for you?
Well, there no magic involved in ClickOnce: you can just look into the deployment folder - is the required file there or not?
If not, you need to change the settings in the Publish options for the required file. This message - in my experience - is always a sign that one of the required assemblies has not been published.
In addition it seems that you published to a mapped network drive instead of publishing to an UNC path. You need to publish to a path following the \\server\name\ scheme.
When I have used the wizard and deployed to a network share, in the Publish Wizard:
Specify the location to publish this application:
UDP Path
Click Next
How will users install the application?
From a UNC path of file share
Specify the UNC path:
The same UDP Path (copy pasted from before)

How can i create a directory in drive C:\?

i am trying to create a directory in drive C: (at a win7 target machine) with Directory.CreateDirectory but so far no luck.
I believe the problem has to do something with permissions-security... So here i am..
How can i create a directory in drive C?
You need to run your application in elevated mode (via UAC). How this can be done is shown in the above StackOverflow thread:
UAC, Vista and C# - Programatically requesting elevation
Before executing the code to switch in elevated mode you should do a check if you application is running on Vista, Windows 7 or above.
You should not use the root of C for an ordinary application. If you're just using it because you think it's a folder you can count on, use AppData or Temp instead. If this is not an ordinary application, but is instead an administrative application, then put a manifest on it requesting it elevate (requireAdministrator) so that it can gain access to the areas of the hard drive and registry protected by UAC.
DirectoryInfo dir = new DirectoryInfo(#"c:\MyDir");
dir.Create();
hope this will help u...