I'm writing a MIDlet which needs to write file. I'm using FileConnection from JSR-75 to accomplish this.
The intention is to have this MIDlet runnning on as much devices as possible (all MIDP 2.0 devices with JSR-75 support, ideally).
On several emulators and an HTC Touch Pro2, I can perfectly use the following code to get the root of the filesystem:
Enumeration drives = FileSystemRegistry.listRoots();
String root = (String) drives.nextElement();
String path = "file:///" + root;
However, on a Nokia S60 5th edition emulator, trying to open a FileConnection to this path throws a java.lang.SecurityException. Apparently S60 devices do not allow connections to the root of the filesystem. I realise I can use something like System.getProperty("fileconn.dir.photos"), but that isn't supported on all devices either.
So, my actual question: what is the best approach to get a path to create a FileConnection with, that allows for maximum portability?
Thanks.
Edit:
I suppose I could iterate over all the roots in the Enumeration, and check for a writable one, but that's hardly optimal for two reasons. First, there aren't necessarily any writable roots. Second, this could be the phone memory or a memory card, so the storage method wouldn't be consistent across devices, which is rather ugly.
You are supposed to open read-only connections to roots in order to find out what folder they contain.
As a general rule, when opening a read_write connection to a folder throws a SecurityException, try to open a read-only connection to browse through sub-folders in order to find a writable one.
Specifically on Symbian (and other platforms advanced enough to provide secure data cages to your MIDlets), you can use System.getProperty("fileconn.dir.private"); to find a writable area.
I will tell you what we do. We have a test app that just finds out the file system root and the SD card root if applicable. We set this as a jad parameter. The code reads it from the Jad file. Since you dont need to recompile the jar for different devices this works out very well, just change the jad parameter for a handset with different file system root.
Related
I'm running Raspbian 1.0, v9/15 on an RP3. I'm working on an application that will access a dedicated USB flash drive to store collected data. The static path to write the data is "/media/user/kingston". This works great unless I have a system crash at which point the owner and group for "/media/user/kingston" are changed to root, and the mount point for the flash drive now is now changed to "/media/user/kingston1" which (clearly) does not work with the static path defined in my application. Is there a standard dynamic path option that is available for this device and OS? Thanks in advance...
Update: Based on BJ Black's advice, this is what I added to fstab after creating a directory named /usb at the root of the filesystem,
/dev/sda1 /usb vfat noatime,nofail,user,rw,exec,umask=000 0 3
The advantages are,
1) allows bootup even when no USB drive is inserted,
2) allows any usb storage device to be used here.
Disadvantage is that the system must be powered down (or drive umounted) before flash drive is removed otherwise bad things happen, (I tried this). Question: Is there anything that I can do to reduce the "bad things" in the event that someone pulls out the usb while it is still mounted? Thanks in advance.
In general, I tend to prefer using a hard mount point for this kind of thing. There are possibly some neat tricks in /sys (or by using a grep against the output of mount(1) or /proc/mounts), but they'll fail as soon as you change out your Kingston stick for some other vendor (yuck).
Have a look at this link to better understand what's automounting your usb stick and how to shut that mechanism off.
As for mounting in a permanent place, I'd try either:
Create a mount point (say /data) and put an entry in fstab(5) so it gets mounted automatically on boot.
Same as 1, but use the noauto and user and do an explicit call to mount(1) from your application, or...
Install autofs and put an entry in auto.misc to automount the device (probably /dev/sda1) on use. Then symlink /data -> /misc/data.
Of these, I like option 3 the best, as the stick will unmount automatically when idle. Then your application need only double-check that the path is writable beforehand.
Also be super-careful on writes, as cheapie USB sticks tend to erase in large blocks and their wear levelling is weak at best (so both small random writes and large writes tend to wear the flash fast). Using f2fs or careful write buffering helps (and the noatime option on mount helps). And don't call fsync() all the time in your app!
Is there any simple way to do this?
I basically want iTunes to not open if an external hard drive is not connected. This is essentially a user issue - as despite asking multiple times, my girlfriend will forget and open an audio or video file without the external HDD connected (where the iTunes library is kept) and so the usual rigamarole occurs... the media file will then try and add itself to the iTunes library, which can't be found, so it'll default back to it's position on the internal hard disk, and then when I come to use it, it'll try and consolidate it for me (which is nice), except it then decides it needs to organise it - and this takes about 6 hours due to the amount of music I have on there.
I've tried changing the internal (default) iTunes music folder path to an alias to the external one, but that starts throwing out some beastly errors once you get into the loop (when the alias is essentially a pointer to an invalid location).
Is Automator something that could be used? Sorry I'm not very pro with OS X I'm afraid.
Thanks,
Duncan
It seems a straightforward way to do this is just to move the iTunes.app onto the external hard drive, and replace iTunes.app in the Applications folder with an alias pointing to iTunes on the external HDD (called iTunes).
As iTunes is system protected, you'll need to change the permissions of iTunes.app to move it, which you can do via gui or terminal (sudo chmod...)
Simples.
I am developing a Win8 Store app which allows users to download different types of files from an online learning platform and store them locally. I am also considering the function to help users organize these downloaded files by placing them in different folders (based on course name and etc.).
I was using Documents Library previously. But for every type of file that the user could download, I need to add a file type association, which does not make a lot of sense since my app would be able to open such files. So which local storage should my app use?
Many thanks in advance.
Kaizhi
The access to storage by Windows Store apps is quite restrictive, especially the DocumentsLibrary.
As you have noticed, you need to declare a file type association for every file type you want to read from or write to the DocumentsLibrary. This means your app need to handle file activations for these types in a meaningful way, which your app probably should not do.
But even if you jump through this hoop, there is another one that is not documented on the MSDN page of the DocumentsLibrary, but "hidden" in a lengthy page about app capability declarations: According to the current rules, you are not allowed to use the DocumentsLibrary for anything but offline access to SkyDrive! Bummer...
So what's left?
You can use SkyDrive or another cloud storage to put files in a well known place (which might or might not be somewhere on the hard disk). This is probably both overkill and undesirable in your case.
Or you save the files in the local app storage, provide your own in-app file browser and open the files with their default app. Seems viable to me.
Or, maybe, you can do something with share contracts or other contracts. I don't know much about these yet, but I doubt that they are helpful in your situation.
And that's it...
(Based on my current experience. No guaranty for correctness or completeness)
Is there a way (via shell extension or registry setting) to tell Windows Explorer that it shouldn't read files in the folder being shown in order to extract metadata or create thumbnails?
The problem is that when the user navigates to the folder, Windows Explorer attempts to read all files in the folder and extract certain metadata from them. If the medium is slow, this takes ages and causes unnecessary load on the file system. This is especially true in case of thumbnails, when the whole graphic file is read.
I am looking for ways to do this (restrict Explorer) in code, so "don't use Thumbnail mode" is not an acceptable answer :).
Upd: per-user settings won't work unfortunately cause we as a disk provider can deal only with our own disk (and the user might want to have separate settings for regular disks and virtual disks). I believe there must be some way to "explain" the OS that the drive is slow.
Maybe there's some IRP on driver level that we need to handle to tell the OS that the medium is slow?
Is there a way (via shell extension or
registry setting) to tell Windows
Explorer that it shouldn't read files
in the folder being shown in order to
extract metadata or create thumbnails?
Not that I know off, but depending on the priorities regarding the use case details you outlined there might be two options still to approximate the desired result:
Via group policy
Note that this essential expands/details the network folder related aspect of Freds answer, which you dismissed in your update; however, you claim to be able to deploy shell extensions or registry settings and the following two group policies simply execute the latter by administrative means:
User Configuration -> Administrative Templates -> Windows Components -> Windows Explorer:
Turn off the display of thumbnails and only display icons **on network folders**
Turns off the caching of thumbnails in hidden thumbs.db files.
This boils down to the following registry settings:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Explorer]
"DisableThumbnailsOnNetworkFolders"=dword:00000001
"DisableThumbsDBOnNetworkFolders"=dword:00000001
Of course this is still not per folder, but at least limited to network folders and ignores regular disks and virtual disks.
Via hackish workaround
Given your statement we as disk provider can deal only with our own disk there might be a hackish workaround, though I'm afraid it lacks the last mile (untested by myself).
Starting from Chris W. Reas own answer to How can I suppress those annoying Thumbs.db files in Windows Vista and Windows 7?:
Also worth knowing: In Vista and Windows 7, Thumbs.db applies to network folders only. For local folders, Vista and Windows 7 instead save thumbnail cache information to a database in a local folder at "%userprofile%\AppData\Local\Microsoft\Windows\Explorer"
Continuing from there, Wil claims the following potentially clever solution to work on a per folder basis:
Go to the drive and create a file called thumbs.db (in notepad or anything), then change the permissions on the file for everyone (including SYSTEM) to deny all.
Unfortunately, aside from the automation requirements to create the dummy thumbs.db in each folder, the outcome depends on how Explorer will react on the inaccessible file - because caching is optional as per group policy, it might as well display thumbnails without caching them, making the bandwidth issue even worse in turn ...
Good luck!
I'm not sure if you can disable thumbnail generation/display for certain folders but this article talks about a script which could quickly disable it via context menu.
The script modifies a value in the registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\. I suppose you could find something similar in that key for the other metadata. ShowInfoTip sounds promising. There might be relevant information in other nearby keys.
This may be a complete non-answer depending on your needs, but how about storing the files without file extensions that the OS wants to make thumbnails of? Call it file.jpg.abc and it won't be reading thumbnails, for sure.
I have a particular file I want to monitor for file read attempts by all applications on OSX. I'd like to be able to interrupt the requests so I could decide which applications have permission to read the file and which don't (by querying the user, or checking a cache of user responses). Is this possible with the OSX API? If not, is it even possible to get a list of which applications or processes do read a file?
I'm not saying there's no way to do this, but what #Jonathan is talking about isn't it.
That API is for tracking the creation, change, and destruction of files. Notably this tool is used by things like Spotlight to watch activity on the filesystem for new, interesting files.
But, wisely, reading isn't one of the events it tracks.
And even if reading WAS tracked, it is still the wrong mechanism, as it's a notification system after the fact, not in line with the call itself.
I seriously doubt what you want is possible the way you describe it.
With Access Control Lists, you can limit access at the user level (Fred can read the file, but Bob can not). This is a setting on the file itself. But there's no mechanism to allow Bobs App1 to read a file, while Bobs App2 can not, since there's really no formal mechanism of "application identity" beyond the command to executed, or whatever the program "says" its name is (both of which can be spoofed if motivated enough).
However, feel free to crawl the Darwin sources -- no doubt the answer is buried in there somewhere near the open(2) call.
EDIT, regarding comment.
What are you trying to do? What's the overall context?
Another thing that you may want to try is to use FUSE.
FUSE is a utility that let's you have "user space filesystems". People use FUSE for many purposes, like reading NTFS volumes, or mounting remote system via SSH.
They have a simple example, that gives you a skeleton that you can fill in for your purposes.
For most of the use cases, you'll simple defer to the system. However, for OPEN you will add your logic. Then you could point your FUSE utility at a directory, and "mount it". Then all of the files below that directory can use your new behavior.
I'm still not sure how you will identify Apps by name, but if it's not a real "security" issue, just for local control, I imaging you can come up with something. Activity Monitor has apps names, so they must be available, and FUSE will be running within the process space (I think), rather than through some external mechanism.
All that said, I think FUSE is your best bet, but it's probably not appropriate if you want to do this to "any file" with no preparation by the user (like not installing FUSE). If you wanted to do "any file", your FUSE system would need to be mounted at root, and then you'll simply have a full "clone" of the filesystem, with those files from the normal root "unprotected", while those from your new FUSE root will be protected. So, if someone wanted to NOT use your FUSE system, the real file is readily available to them through the actual file location.
If not, is it even possible to get a list of which applications or processes do read a file?
The command-line tool fs_util allows you to monitor filesystem activity, including reading.
The writings of Amit Singh should come in very handy. He explored the API that provides FileSystem events a few years ago, and provided a sample tool that allows you to intercept FS events. It's open source!
If i remember his conclusion properly, their isn't an official API, but you can use apple's tools to achieve what you want.