In the workspace we have a set of resource files which contain contents in it.
Problem: When I select the project we can get the resource file and now we want to clear the contents of the file. So we tried to get the resource file as IFile and if we try to use the IFile::delete() method it is deleting the resource file from workspace instead of clearing the contents.
How can we clear the contents of the IFile present in the workspace without deleting the IFile form the workspace?
Use IFile::setContents() to change the contents of a file.
To clear the content of the file, use an empty input stream:
InputStream newContents = new ByteArrayInputStream( new byte[ 0 ] );
IProgressmonitor monitor = ...
file.setContents( newContents, IResource.KEEP_HISTORY, monitor );
The KEEP_HISTORY flag keeps the previous contents in the history so that user could go back to earlier versions with Replace With > Local History. If that's not desired, use IResource.NONE.
Related
For example, my podcast app has a list of all downloaded podcast, how do I get a list of all LockCachingAudioSource that has been downloaded using request() method?
When you create your LockCachingAudioSource instances, you can choose the location where you want them to be saved. If you create a directory for that purpose, you can obtain a directory listing using Dart's file I/O API. The directory listing will also show partially downloaded files and other temporary files, which you want to ignore. These have extensions .mime and .part.
Having explained that, here is a solution. First, create your cache directory during app init:
final cacheDir = File('/your/choice/of/location');
...
await cacheDir.create(recursive: true);
Then for each audio source, create it like this:
import 'package:path/path.dart' as p;
...
source = LockCachingAudioSource(
uri,
cacheFile: File(p.joinAll([cacheDir, 'yourChoiceOfName.mp3'],
);
Now you can get a list of downloaded files at any time by listing the cacheDir and ignoring any temporary files:
final downloadedFiles = (await _getCacheDir()).list().where((f) =>
!['mime', 'part'].contains(f.path.replaceAll(RegExp(r'^.*\.'), '')));
If you need to turn these files back into the original URI, you could either create your own database to store which file is for which URI, or you choose the file name of each of your cache files by encoding the URI in base64 or something that's reversable, so given a file name, you can then decode it back into the original URI.
In my Scala code I want to create a folder "c:/temp" and then create a file "file.txt" within that folder. I don't want to have to use "c:/temp/file.txt". So, I want to use the relative path of the file to create it within that folder.
Imagine how a human creates a folder and then a file? He creates a folder; goes in the folder, and then creates the file inside that folder. That's what I want to do.
=====
Added the following to make this more clear:
Let's say I created the folder and I have a File object called myFolder that represents that folder. What I want is to be able to do something like myFolder.createFile("file.txt").
val subFile = new File(myFolder, "file.txt")
From the description of the File(File parent, String child) constructor found at the docs page:
Creates a new File instance from a parent abstract pathname and a child pathname string.
I am trying to upload some files to dropbox using their java API (version 2-beta-4), but some of these files have the same name.
What I would like to know is: What is the reason for I send a file (for instance "file.txt") to dropbox, this file is uploaded, but if I send another file with the same name (file.txt) dropbox overwrite the old file with this new one instead of renaming it to "file (1).txt", even I am setting autorename true and the WriteMode to add?
Code:
DbxRequestConfig config = new DbxRequestConfig("sample", "pt_BR");
String acessToken = "...";
client = new DbxClientV2(config, accessToken);
InputStream input = new ByteArrayInputStream(file.getBytes());
FileMetadata file = client.files.uploadBuilder(path).mode(WriteMode.add).autorename(true)
.mute(true).run(input);
Thanks.
WriteMode.add is what's causing this behavior. "Add" means "Add a new file with this name," so it never overwrites an existing file. If you want to overwrite the existing file, use WriteMode.overwrite.
(Also, isn't it WriteMode.add() and WriteMode.overwrite()? I thought those were methods.)
I am doing some serialization which also contains an IFile path that needs to be stored as string.
I am using this IFile in a plugin project. For debugging or running Eclipse starts a new workspace. This testing-workspace has its root somewhere relatively to the plugin folder. My problem is, when I turn my IFile to an absolute path, my Eclipse testing-workspace considers the file as outside the workspace and throws exceptions.
If I use the project relative path, the IFile creation from string fails and IFile is null.
I truly want to believe that it works the way I need it, but I really would like to see it. Is there a way to reconstruct a valid IFile from a project relative path?
Currently, I am doing the reconstruction from String->IFile like this:
//name is a string with the absolute path
IPath location = new Path(name);
IFile file = project.getFile(location.lastSegment());
But, like already mentioned, works only with an absolute path, which doesn't work in the eclipse testing-workspace.
Thanks for a hint
You are very close. You want:
IPath path = new Path(name);
IFile file = project.getFile(path);
The name should be an absolute (to the workspace) or project-relative path. This interface is defined in IContainer.getFile(IPath). I changed the variable from "location" because location is usually meant as the actual (local) OS file path. To get the path use:
IPath path = file.getProjectRelativePath();
I have some problems updating an "old" Eclipse plugin. Here is what I would like to do and what the original plugin did:
(parse compiler output on console with file name and error information --> still works)
--> set link to the location within the file
--> set marker to location in the file
What I did in the past was to get the IFile from the path String of the file and generated link and marker from it:
IFile ifile;
IWorkspace workspace = ResourcesPlugin.getWorkspace();
IPath path = new Path(fileName);
IFiles[] files = workspace.getRoot().findFilesForLocation(path);
...
ifile = iFiles[0];
Map attributes = new HashMap();
attributes.put(IMarker.SEVERITY, new Integer (severity));
MarkerUtilities.setLineNumber(attributes, lineNumber);
MarkerUtilities.setMessage(attributes, message);
MarkerUtilities.createMarker(ifile, attributes,
IMarker
Since findFilesForLocation is deprecated, I tried to find another way but I am not succeeding whatsoever. Using the changed code to get the IFile always results in a exception: org.eclipse.core.internal.resources.ResourceException: Resource '/path/to/file.c' does not exist.
Is it possible that this relates to the fact that the source file is only linked into the project, and not physically within the project?
IWorkspace workspace = ResourcesPlugin.getWorkspace();
IPath location = new Path(fileName);
IFile ifile = workspace.getRoot().getFile(location);
Can anyone help?
Thank you!
I am guessing that fileName is the fully qualified path to the file you want to get. I'm also guessing that the file that you are looking for is already in the workspace, even if it is linked (if not, then this won't work. You will first need to add the file to a project before getting the IFile for it).
You need to do something like this:
IFiles[] files = workspace.getRoot().findFilesForLocationURI("file:" + fileName);
Then this will find all files in the workspace that correspond to the file in the file system.
The reason why your attempt above is giving you a ResourceException is that you are trying to pass in a file system path to get an IFile object from the workspace. The Eclipse workspace is an abstraction over the underlying filesystem and cannot directly work with absolute paths.
For the Resources APIs, Paths usually means a path in the workspace and Location usually refers to a place in the filesystem or outside the workspace. If you already have a workspace path to start with, just ask the IWorkspaceRoot for the IFile and get on with what you're doing.