I want to save data to my Sony Ericsson K750i. I know the phone implements FileConnection version 1.0. The list of roots taken from
FileSystemRegistry.listRoots();
returns single element named "c:/". I want to save a file.txt just about anywhere, but preferably to the memory stick attached. Unfortunately, it doesn't seem to work. It throws an IOException without any message. I tried opening the fileconnection on numerous roots like c:/, C:/, /, ./, root1/, SDCard/, CFCard/, MemoryStick/ and perhaps some more but without any luck.
The exception is thrown right after this line for any of those roots:
FileConnection filecon = (FileConnection) Connector.open("file:///MemoryStick/file.txt");
Please, what URL should i use?
I would suspect that your problem is that you are trying to write a file in a location your MIDlet isn't allowed to write to.
My guess is that you can read "c:/" just enough to figure out what its subfolders are. You can't create a file or a subfolder.
However, browse through c: subfolders and there should be a location somewhere where you can create a subfolder and/or a file.
Of course, all this assumes that your MIDlet is signed with a certificate that puts it in a security domain allowing good enough file system access.
Related
fellow developers.
Let's imagine the following scenario: A group of friends is playing Minecraft on a server. That server has a resource pack associated (file server.properties, field resource-pack). That resource pack is a ZIP file hosted by Dropbox, and the respective Dropbox share link is what goes on field resource-pack.
All good, for now. Resource pack loads flawlessly.
However, those friends need to update the resource pack with their custom textures every now and then. I'd like to automate that process in the best way possible. To provide a custom texture, one needs 2 files: a .png file and a .properties file. Those are fairly easy to make. Then, those files need to be put in the following directory (Dropbox):
/ResourcePack.zip/assets/minecraft/optifine/cit/
The problem here is that the Dropbox API can't upload to existing ZIP files, and the resource pack has to be a ZIP file, int order for Minecraft to recognize it. Also, I don't want to download the ZIP file, extract, put the files inside, compress and upload again, because it's quite a large file and that would take some time.
My Java application looks like this:
What the application does now, is accept dragged files and send them to the Dropbox path:
/ResourcePack/assets/minecraft/optifine/cit/
But not:
/ResourcePack.zip/assets/minecraft/optifine/cit/
I was told the Dropbox API can't handle uploads to ZIP files, and I also can't find anything on the documentation here.
Can anyone think of a solution, other than downloading the full resource pack, and uploading it back everytime someone wants to add custom textures?
Thank you.
EDIT:
So, as Adriaan suggested, I can simply use a direct link to the unzipped directory structure of the resource pack.
The problem is now another:
When a player joins the server, and downloads the resource pack for the first time ever, everything is fine. However, it gets cached in his local machine, in the following path:
/.minecraft/server-resource-packs/
So, when the resource pack is updated with new custom textures, minecraft will just load the cached resource pack and ignore any updates present in Dropbox. This results in the player not seeing the new custom textures.
I've learned about the resource-pack-sha1 field in server.properties. It looks just like what I need, but I can't quite understand how to use it.
Thanks in advance.
You can store the unzipped directory structure. DropBox allows downloading a directory as a zip file.
You can force dropbox to do a direct download by changing the dl=0 at the end of the URL to dl=1 see this help page
If the remark on the page you linked is still true "This is not yet used to verify the integrity of the resource pack, but improves the effectiveness and reliability of caching." then you could just enter a random new value into resource-pack-sha1 to trigger all clients to download the new pack.
If you need the actual digest then you could follow this mini tutorial
to generate an SHA1 for your server.properties:
visit this website: http://onlinemd5.com/
Upload your resourcepack
copy the SHA1 and paste it into your server.properties for the resource-pack-sha1 option
all done!
If you don't want to upload your resource pack to someone else's server you could download a tool to determine the digest locally.
Note: DropBox offers a content hash via their API, but it's not an SHA1 over the complete file. Rather they split the file in 4 MB blocks and determine the SHA256 for each, concatenate them and SHA256 the result again. If there's a way to change the hashing algorithm used by Minecraft this could be used.
EDIT: Is it an option to rename the resource pack directory on DropBox when you change its contents? This will circumvent the caching and hashing issue. Clients will just need to change the resource pack URL accordingly.
I'm developing a Java software that reads lots of possibly big files.
I'll try to parallelize it, so it reads in parallel files from different devices (HDD, SSD, flash drive, SMB, etc) and only 1 file at a time from each device. But for that I'd need to know in which device a given file is.
On Windows I guess I could just use substring its path for the drive letter, but for Linux I have no idea how that could be done. Is there a standardized way to do it?
The sun.nio.fs.UnixFileAttributes class, which is used for PosixFileAttributes, contains a st_dev field. Unfortunately, it is not public accessible, you might have to use reflection to get the value.
A different approach would be to call stat on the file and read the device id that way. Then you can use the device id to find out which device the file is on.
Also you might want to check the output of mount to check the paths you are using and where they are mounted on.
Linux Api has O_TMPFILE flag to be specified with open system call creating unnamed temporary file which cannot be opened by any path. So we can use this to write data to the file "atmoically" and the linkat the given file to the real path. According to the open man page it can be implemented as simple as
char path[1000];
int fd = open("/tmp", O_TMPFILE | O_WRONLY, S_IWUSR);
write(fd, "123456", sizeof("123456"));
sprintf(path, "/proc/self/fd/%d", fd);
linkat(AT_FDCWD, path, AT_FDCWD, "/tmp/1111111", AT_SYMLINK_FOLLOW);
Is there a Java alternative (probably non crossplatform) to do atomic write to a file without writing Linux-specific JNI function? Files.createTempFile does completely different thing.
By atomic write I mean that either it cannot be opened and be read from or it contains all the data required to be writted.
I don't believe Java has an API for this, and it seems to depend on both the OS and filesystem having support, so JNI might be the only way, and even then only on Linux.
I did a quick search for what Cygwin does, seems to be a bit of a hack just to make software work, creating a file with a random name then excluding it only from their own directory listing.
I believe the closest you can get in plain Java is to create a file in some other location (kinda like a /proc/self/fd/... equivalent), and then when you are done writing it, either move it or symbolic link it from the final location. To move the file, you want it on the same filesystem partition so the file contents don't actually need to be copied. Programs watching for the file in say /tmp/ wouldn't see it until the move or sym link creation.
You could possibly play around with user accounts and filesystem permissions to ensure that no other (non SYSTEM/root) program can see the file initially even if they tried to look wherever you hid it.
In my Android App I save some files with some data file using
FileOutputStream savedList = new FileOutputStream(Path);
in a folder named myApp located in the SD storage
Unfortunately I have noticed that some cleaner Apps, not well implemented, also very popular (e.g. CleanMaster) wrongly remove the files every time the user perform a temp\trash file cleaning causing problems.
Is there a way to protect (and unprotect for writing) the file programmatically to avoid this?
How to change file permissions?
Since aren't used the file extensions to recognize the file format, how could I change the metadata of the file that are used to determine the file format so that these file are see as documents by these apps? I suppose that the scan of these Cleaners use some strategy based on Linux file format recognition and remove all object files.
Android allows to have private directory on SD card for the app.
you can get the path for private directory for your app as follows.
File myDir = getExternalFilesDir(null);
The null parameter indicates that you are going to store any type of files in the directory
myDir.mkdirs();
Log.d("info", myDir.getPath());
These files are internal to the applications, and not typically visible to the user as media.
This is like getFilesDir() in that these files will be deleted when the application is uninstalled, however there are some important differences:
Shared storage may not always be available, since removable media can be ejected by the user. Media state can be checked using getExternalStorageState(File).
There is no security enforced with these files. For example, any application holding WRITE_EXTERNAL_STORAGE can write to these files.
This solution worked for me as cleaning apps on devices don’t clean these folders considering them as private folders for the respective apps.
Checkout following link from android docs. Context.getExternalFilesDir(java.lang.String)
Write it to your private internal drive, so they don't have permission to touch it. SD cards are just FAT32 drives, so they don't support file permissions or access lists.
On 4.4 phones you may be ok, as Google basically prevents any writes to the SD card outside of a private directory. Cleaner type apps won't work on it at all, for better or worse.
First, you should read the first answer of this question. The thing to remember :
No, Environment.getExternalStorageDirectory() refers to whatever the device manufacturer considered to be "external storage". On some devices, this is removable media, like an SD card. On some devices, this is a portion of on-device flash.
The SD card is a vague notion, it's quite impossible to be 100% sure you are writting on the SD card.
That thing said, you should use the Android API to write your file on the private directory of the app, located in /path/to/external/storage/whatever/it/is/on/the/device/Android/data/com.package.yourapp/files
Use getExternalFilesDir to get the above File and write your file on the private directory of your app, this way, no one will be able to delete it.
I have an app which converts jTable instances into an excel file. In my previous question, I had a problem in using FileOutputStream() and it turns out that the problem lies within the AD user's privilege in accessing folders/files. Since my superior wont allow me to change the privileges, I resorted using the FileWriter() instead, which worked well. The only problem is that it kept on warning the users that the file they are opening is corrupt. Here's the warning:
The file you are trying to open, 'filename.xls' is in a different format than specified by the file extension. Verify that the file is not corrupted and is from a trusted source before opening the file. Do you want to open the file now?
I searched for a solution which resides in Excel 2007's file extension security. Info can be found here
I made some configuration in the system registry of every workstation that the app covers.
I just want to ask if there's a away to remove the corrupt file warning in Office 14, because one of the workstation, which is my superior's workstation, has Office 14. The changes in the system registry didnt stop the corrupt file warning in his workstation.
I get the impression that you are indulging in "voodoo programming" practices; i.e. applying solutions that you don't understand to problems that you don't understand.
Firstly, this:
I had a problem in using FileOutputStream() and it turns out that the problem lies within the AD user's privilege in accessing folders/files. Since my superior wont allow me to change the privileges, I resorted using the FileWriter() instead, which worked well.
Frankly, this doesn't make sense. If you cannot open a file using new FileOutputStream(File), then you shouldn't be able to open it with new FileWriter(File). Why? Because the source code for the constructor is this:
public FileWriter(File file) throws IOException {
super(new FileOutputStream(file));
}
In other words, the first thing that the FileWriter constructor does is to call the FileOutputStream constructor that you say doesn't work!! (And the same applies to the other overloads of these constructors.)
Then your current problem is really about Excel not letting you open an XLS file because its filetype doesn't match its suffix. And your proposed solution is to mess around with the registry. But surely, the CORRECT approach is to find out why the file type doesn't match the suffix.
Have you made a mistaKe in the file format (e.g. 'cos you wrote it using a FileWriter)?
Have you chosen the wrong file suffix for the spreadsheet format you've used?
Are you downloading it to the user's machine with the wrong MIMEtype?
Banging on the registry on all of the client machines ... just because you read it in some website ... that's Voodooo!
I'm not surprised that your boss forbade you to mess around with AD privileges. At this point, he's probably worried that you'll do serious damage.
By the way, your registry hacking to make the warning go away is actually turning off a security check that is designed to help harden the user's PC against attack. That doesn't strike me as a sound solution to your problem.