On Wed, Jun 23, 2010 at 10:08:06PM -0400, ian geiser wrote: > Greetings, I have been working on adding the ability to expose local file > systems to a remote instance of qemu. I have decided that since there is > already a connection from the client to the VM with the RFB protocol that I > want to extend that. I have spent some time researching the current > approaches that VNC uses to transfer files between the client and the host > and > none of them seem to offer a solution I like. The NFS approach is too > cumbersome at this point, and transferring entire files to the host before > they > are accessed is also prohibitive. So I started on the following approach: > > http://www.geiseri.com/sharedfolderspec/sharedfolderspec.html
Hello, I must admit your proposal looks very promisingly. I googled about a hour and I didn't find any useful network FS which can be easily used together with VNC. All file systems require superuser privileges and are system-wide oriented instead of per-user oriented, which we need in VNC. > This approach is a bit different in the way that the server initiates all > file > access, and it accesses data from the client on demand. This is done via a > block based approach so only the desired data is read from the client's file > system. Also I tried to make the messages mesh well with the API's of > Microsoft's file system driver and the FUSE file system driver. The goal > being > that the VNC session would expose these shares as part of the local file > system. Since the implementation I am working against on qemu only supports > the vfat file systems I have mirrored most of the behavior against that. The > only casualties so far have been symbolic links, special files (sockets, > devices, etc), user ids and group ids. For 99% of the applications out there > this should not be an issue. Please someone correct me if I am mistaken > though. My main use case is to share my local USB key with my VM. > > I am looking for feedback from other VNC implementors to see if they are > willing to entertain this extension. It would be nice if there was a way to > share client data with the host similar to how Microsoft does it with their > terminal services. (For those of you who have worked with the RDP protocol > this is going to look eerily familiar) Just a little suggestion, please add a "Version" field to the "Request enable share" and "Client enable sharee" messages, I'm sure this extension will have improvements in the future. In my opinion your current proposal is too client->server transfer specific. Instead of that I would suggest to create more generic "RFB mounts" which will allow transfers in both directions. I think it shouldn't be hard to mark messages as "bidirectional". I have one question, about your goal. In the end, would you like to have possibility to mount remote directory hierarchy to local filesystem (on UNIX) or to create something like network disk on Windows? If yes, it will be really great. Regards, Adam -- Adam Tkac, Red Hat, Inc. ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
