IFileService doesn't support binary data #41543
Assignees
Labels
Milestone
Comments
|
I have pushed a workaround that prevent data loss tho the issue remains... |
|
I think changing from Since 99% of all users of this method want the Still, the issue with layering remains. |
A buffer is just an Unit8Array which is available anywhere so I don't believe that's a problem. See https://nodejs.org/dist/latest-v8.x/docs/api/buffer.html#buffer_buffers_and_typedarray. |
|
Ok so that is helpful. |
|
As discussed - We should have methods that return streams (readable, writable) which return bytes or strings depending on the presence of a encoding. Maybe no encoding guessing in those methods? |
|
This also prevents copying data from a 'remote' file onto the local disk |
|
I've added the proper interface for a binary file and the interface method, but I don't want to pull request anything until I've fully implemented everything that needs to exist for this to work. As of right now it's just extra optional code that's been added that doesn't change much of anything. I'm not a typescript programmer specifically but I know enough to be dangerous. I'm also not really familiar with the codebase yet, but there's no reason that VSCode can't have a kick-butt FTP/SFTP/etc client built in without the need for an extra client like Cyberduck or Filezilla. remote-workspace shows a lot of promise in that area but it doesn't work completely and part of that has to do with the lack of binary support in the filesystem provider. I would love some feedback on what needs to be done or even to work with one of the developers to make this happen. But this is what I've done so far: index b007b6f184..2fe8e61d9f 100644
--- a/src/vs/platform/files/common/files.ts
+++ b/src/vs/platform/files/common/files.ts
@@ -90,6 +90,13 @@ export interface IFileService {
*/
resolveContent(resource: URI, options?: IResolveContentOptions): Promise<IContent>;
+ /**
+ * Resolve the contents of a binary file identified by the resource.
+ *
+ * The returned object contains properties of the file and the full contents as a byte array.
+ */
+ resolveBinaryContent?(resource: URI, options?: IResolveContentOptions): Promise<IBinaryContent> // This should be optional for now.
+
/**
* Resolve the contents of a file identified by the resource.
*
@@ -465,6 +472,32 @@ export interface IContent extends IBaseStat {
*/
value: string;
+ /**
+ * The Mime Type of the file if known
+ */
+ mimeType?: string;
+
+ /**
+ * The encoding of the content if known.
+ */
+ encoding: string;
+}
+
+/**
+ * Content and meta information of a binary file.
+ */
+export interface IBinaryContent extends IBaseStat {
+
+ /**
+ * The content of a binary file or text file treated as binary.
+ */
+ value: Uint8Array;
+
+ /**
+ * The Mime Type of the file if known
+ */
+ mimeType?: string;
+
/**
* The encoding of the content if known.
*/ |
|
The lines below seem to reference the |
bpasero
added
bug
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The contract for resolving a file is to return
IContentwithvalue: string(or the string-stream equivalent). That API prevents us from doing a few things, such as previewing images from remote sources (see #34773) and things like drag and drop of files between different file systems, esp between thefile-support and others.An easy way to corrupt your data is:
IMO the better API would be to just talk about bytes or chunks of bytes and turn things into a string later, e.g in the text file service. That would allow to pump data from one provider onto another provider, it would also allow to build data-uris for remote images.
The text was updated successfully, but these errors were encountered: