[feature-request] Shared Folders should use ISO9660 filesystem instead of vboxfs

[Technologov]

Hi All !

Current model of dealing with shared folders have few big drawbacks.

1. Guest Additions must be installed

2. Mount of shared folders in guest is not automatic

It is possible to kill both hares in one shot.

The "Shared Folder" must appear in guest as DVD-ROM (ISO9660) filesystem, instead of current vboxfs.

Since ISO9660 is supported by all kernels of all OSes, this will be a killer technology.

Of course there are drawbacks:

1. limits on file sizes
2. Read-only mode

But it will help people a _lot_.

This means that VirtualBox should take files on host OS, and convert them on-the-fly into ISO9660 filesystem to be viewed by guest.

Alternatively, SMB Server can do similar function (if embedded into VirtualBox), but DVD-ROM is easier to use.

-Technologov, 16.8.2008.

[Terry Ellison]

+1 though perhaps as an alternative to vboxsf rather than a replacement. What we could do here would be to add this as a third radio button on the CD/DVD-ROM dialogue (plus VBoxManage controlvm command).

The issue that I haven't got my head around is that the Guest ISO9660 driver assumes that the device is a fixed cacheabe block format so there are lots of issues around locking and integrity that may just make this technically unrealistic, so architecturally smb is a closer fit.

[Mike Swanson]

ISO-9660 has some limitations which makes it impractical compared to the current method. Specifically, file sizes, directories, file names, and limitation of volume size.

Some alternatives to either vboxsf or ISO-9660 I can think of:

1. FAT16: Supported by MS-DOS even (which doesn't do CD-ROMs out of the box), though this also has serious limitations. This is the route QEMU takes.
   
2. FAT32: MS-DOS <= 7.0 (including original Win95/Win95A), WinNT <= 4.0 (without additional ​fastfat32 driver) no support. Similar limitations to FAT16/ISO-9660 however.
   
3. ext2: Supported by practically everything except for Microsoft operating systems (without additional ​tools or ​drivers), however it alleviates restrictions (more relaxed filenames, bigger volumes, large files, etc).
   
4. NTFS: Virtually everything except MS-DOS (without additional tools or drivers) supports it at least read-only. Recent Linux distros typically include ​NTFS-3G by default for full read/write support, FreeBSD and NetBSD also have FUSE + NTFS-3G support; old Linux distributions could use ​Captive NTFS for write support if the user has a Windows XP license (it emulates NT filesystem driver APIs). Filesystem creation and population code could probably be borrowed from the ​Linux-NTFS project (mkntfs, ntfscp, etc).

[Mike Swanson]

After all that previewing and re-editing of the original post, I still have some things unmentioned:

• The approach QEMU takes is to emulate a secondary hard disk with a single FAT16 partition. This prevents the changing of the directory safely on the host, or changing where it points to, etc. An alternative is to emulate USB storage sticks, but MS-DOS and Windows 95 original/95A do not support these without additional drivers (don't remember the names or where to find them); also, while Windows 95B/95C/98/98SE/Me support USB devices in general, they do not support USB storage sticks by default without an additional driver (again, I don't remember the names or where to find them. Windows NT 4.0 and lower also does not support USB or USB storage, but you can install a driver from ​here (comes with some earlier digital cameras, so it has extra junk software that isn't required...).
  • USB also allows mounting multiple directories under the guest, just like the current vboxsf solution.
• I would have provided a link to NTFSDOS (the free version was read-only, and it required a Windows NT license (emulated NT filesystem drivers like Captive NTFS)), however SysInternals which made the driver was purchased by Microsoft, and some of their utilities have been removed because they were too revealing of Microsoft operating systems (Microsoft held the statement for a long time that it was absolutely "impossible" to support NTFS under the MS-DOS design).
• Yet another file system to consider would be ​UDF, which is normally used on optical media so it can also be implemented by emulating another optical drive. This one I'm not quite sure of in terms of support, but I believe Microsoft Windows 98 and higher support it out of the box. Again, I'm not familiar with it or any utilities/drivers to use it under operating systems that don't support it out of the box.

[arny]

I'd vote for either a FAT filesystem (either) or UDF. I guess FAT would be easier to use.

[Frank Mehnert]

Sorry, but this feature request is not critical.

[Terry Ellison]

Frank, I've been thinking about this one. The real functional requirement is to be able to share r/w file systems between the guest and host non-concurrently when GA isn't installed or supported by the guest OS.

For Linux hosts this is really a minor since you can always map a static VDI onto a loop device. We just need to document this properly. (I'll document this on the forum to begin with). I still need to work out an equivalent approach for NT hosts. I'll come back on this with a recommendation. Terry

[Technologov]

This bug has a similar bug #1122

[Michael Thayer]

Just a few thoughts of my own here (I'm afraid this is not a prelude to coding something :) ) It seems to me that most of the things that can reasonably be done by VirtualBox to support this request are already done now. As Terry pointed out, the shared file system can't be used concurrently by the guest and the host, unless it is some special filesystem designed for this, which will probably require installing drivers on the guest anyway (so that you might as well use shared folders).

Network filesystems would be an alternative, but that can already be set up without changes to VirtualBox. With a bit of fiddling with appliances/server VMs, shared folders and internal networks, you can even make sure that the network filesystem is only visible to other VMs.

And if you are going to live with the fact that the guest and the host can't use the filesystem simultaneously, it seems to me that this request boils down to some tool (on the host) which could duplicate a directory on the host to a VDI, ISO image, floppy image or whatever with a filesystem on it, and the synchronise it back after the VM has finished using it (it would be nice to lock the host directory in some way while the VM is running of course, but that is rather tricky).

Did I miss anything here, other than a bit of packaging to make it all nice to use?

[Terry Ellison]

michael, such a tool would require development effort, have quite a few drawbacks and limitations, and therefore only be of interest to a small niche of users. So I doubt that this will be viewed as a high priority. What I keep coming back to is: if you don't want to install GA on the guest, then why not just use samba / NTFS shares on the host (or on the guest) and then you an easily fileshare using standard network filesharing protocols.

The more I think about it, the more I see this one as a dead duck. Sorry.