-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mount local files to the file system #98
Comments
There is no easy solution for this. The API you mentioned is not supported by anybody in practice: https://caniuse.com/#feat=native-filesystem-api. We have some ideas on how this could be implemented, but there are complexities both on the technical side (i.e. how to access the files from the browser sandbox) and the UX side (How to let the user select the files from without breaking the consistency of the virtualized file systems) |
Thanks for the answer. I agree both challenges exists, however I think at least we can aim for mounting the files and folders that already exposed to the browser sandbox. That will enable accessing to large files on disk (read only) which is critical for my application. For the UX, what I have in mind is to display a folder on the virtual desktop where user can select more files or drag and drop files to that folder, these files will then be seen in the java app. This isn’t ideal, but at least allow the work to be done. |
In the short term what we could offer is to support more data types (beside String and Uint8Array) in the /str/ filesystem. We could for example allow to mount File objects so that they could be read progressively. As usual how much priority this additional feature gets depends on the commercial interest for it. |
Sounds good, thanks! |
@alexp-sssup |
@alexp-sssup I tried for quite a while on this, but couldn't make it through. Please take a look at the function strReadAsync(fileData, fileOffset, buf, off, len, flags, p)
{
assert(len != 0);
const file = fileData.parent.files[fileData.path]
const fileChunk = file.slice(fileOffset, len + fileOffset);
const fileRef = {fileChunk: fileChunk, readLength: 0}
function readFile(fileRef, buf, a){
const r = new FileReader();
r.thread = currentThread;
r.onload = function(evt) {
if (evt.target.error == null) {
buf.set(evt.target.result);
fileRef.readLength = evt.target.result.length
cheerpjWakeThread(r.thread)
}
}
r.readAsArrayBuffer(fileRef.fileChunk);
cheerpjPauseThread(a)
}
const a={p: p, f:strReadAsync,pc:0,fileData:fileData,fileOffset:fileOffset,buf:buf,off:off, flags:flags,len:len};
a.pc=0; readFile(fileRef, buf, a);
return fileRef.readLength;
}
// use strReadAsync
const StrOps = { statAsync: strStatAsync, listAsync: strListAsync, makeFileData: strMakeFileData, createDirAsync: null, loadAsync: strLoadAsync, renameAsync: null, linkAsync: null, unlinkAsync: null };
const strInodeOps = {readAsync: strReadAsync, writeAsync: null, ioctlAsync: null, commitFileData: null, readPoll: null }
... |
Being able to mount TypedArray under /str is very practical feature, and this is how I send data to the java app.
However, if it's a huge file (e.g. several GB), it's not possible to load them into the memory. Ideally I would like to mount directly a file or a folder that I selected or drag'n'drop into the file system. This will hopefully enable reading file content on demand.
For now it should be possible to build that as a readonly file system, and in the future it will be possible to use the Native File System api to support writing.
Do you have a quick solution for this? Otherwise I may try to hack around by following the example you have for
CheerpJDataFolder
.The text was updated successfully, but these errors were encountered: