VirtualVolume deprecated without explanation

Hello,

In the latest Xojo build, the VirtualVolume gets deprecated. The Feedback report just goes along the lines of “we should do this”. Is that not a little bit poor to deprecate something?
I’m asking because this is fairly common in Xojo and doesn’t look fair.

Hi Arnaud,

I don’t know the precise motivation to deprecate VirtualVolume, but probably has to do with underlaying changes in the current OSs and their file systems.

Anyway, being deprecated means that you still can use it… probably for long, long enough so you have time to find a workaround or alternative strategy.

[quote=467206:@Javier Menéndez]Hi Arnaud,

I don’t know the precise motivation to deprecate VirtualVolume, but probably has to do with underlaying changes in the current OSs and their file systems.[/quote]
Hello Javier,

Thanks for your answer.

I’m hardly convinced by this. The only file system that I’m aware has changed is APFS replacing HFS+; it’s true I don’t know how VirtualVolumes are implemented, but I can’t think it uses anything technically beyond a binary stream and maths.
Now, given this statement, it looks like one could create its own “VirtualVolume” format quite easily, but (1) that’s not worth removing something if it should be redone and (2) it’s going to be a challenge to save all file references to the master file (just removing one file is going to rewrite all the master file, for instance); that means re-inventing a file system, basically. And speed is faster when the framework does the trick…

I wish… I’m accustomed that, on Apple and Xojo, deprecated things go away far faster than new things and improvements…

So long time that when the day it is removed, the forum is flooded with questions ike “my code that worked fine until now, do not works anymore and I do not know why” (Graphics: recent example #1).

And Xojo cannot do anything * because it does not know when the people decide to step from an old version to the current one (where GDI++ was removed; recent example #2).

  • Something can be done at compile time / with a Preference (remind me Deprecate items): display the list of deprecated items with the Xojo IDE version / date automatically (yes, just display the list).
    And in the docmentation page who talks about deprecated, a link to a page that explain how to change the code (gives a workaround).

It’s not too difficult to create your own. A real simple solution would be something like.

bis.writeUint16 len( filename )
bis.write filename
bis.writeUint64 len( data )
bis.write data

~ repeat for next file.

Do the reverse when reading the file.

The biggest complication comes from replacing the data with larger content.

I still remember doing my own solution with rb 5.5… not super easy, but doable and fast enough (even when the “file” grow in size).

[quote=467212:@Sam Rowlands]It’s not too difficult to create your own. A real simple solution would be something like.

bis.writeUint16 len( filename )
bis.write filename
bis.writeUint64 len( data )
bis.write data

~ repeat for next file.

Do the reverse when reading the file.[/quote]
That’s the easy part (along with actually encrypting the data, which a VirtualVolume seems to do).

That’s somehow what I meant with my statement “just removing one file is going to rewrite all the master file”. Perhaps the VirtualVolume class has that requirement too (rewriting the whole file when one subfile changes, even if there are less data than previously). For small files, that’s probably unnoticeable; if there’s just one “large” file and even if you just replace a one byte file with another byte, it would take time (the user may not understand why writing one byte takes 15 minutes…).

However, your reply made me remembering I have already made my own archive format, which I use for updating my apps (among other things); I could adapt it to more needs…

Thanks.

Suitable when a sub file is, say, 3 GB in size?
(well, I don’t remember if a VirtualVolume is better anyway…)

Are sparse bundles still a thing?

On Macs, yes; good idea. That can suit a lot of needs but it lacks preventing the user to see the content (including removing/modifying one single file and the bundle gets “corrupted”).
On other systems, only regular folders would show. On Windows, the “adopted concept” is that users should deal as less as possible with the file system, so hiding folders should work. On Linux, I’m not sure…

It’s a good idea under certain circumstances, certainly a lot, but creating “archives” (i.e. files that bundle other files where the user shouldn’t modify related data) is still a need sometimes.

Thanks.

As another option, wondering if encrypted SQLite in combination with temp files (for operating on “selected” archive once “extracted” from the DB) would do the trick in your case… that is easy to implement and Multiplatform.

This option would work, I presume.
In my case, I’ve never used databases and am not in ease with the principle: letting another “component” do the actual work.

So, for many people, a database is a solution.
For others, it’s making a custom file format.

Are we done with the VirtualVolume? It depends whether the speed provided by the framework is superior than writing from code…

Thanks.

I don’t care the reasons why the deprecation. I can only suppose some technicality, perhaps at the OS level, makes it difficult to keep.

Nevertheless, after trying VirtualVolume a while ago, I was quite disappointed. It is not a true virtual volume, since it is merely a random access file in disguise. I could have the use for a true virtual volume, but that is not that one.

Do you mean a volume, like the file system object (having a mount point and a file system)?

Indeed.

A mounted virtual volume stored in a file on some arbitrary drive would be a very useful function

There are lower level APIs, in fact kernel mode system to do this like the popular ‘CallBackFileSystem’ but they’re not cheap, and there are no examples on how to use them in Xojo even if you spent the thousands of dollars required for the license.

For the Mac, you can use a DMG file, there’s commands to create a DMG and mount it so that it’s not visible to the user (In Finder at least).

You could also use a zip file. My zip classes (written in pure Xojo code) can even handle duplicate files in the same folder, not sure if other zip offerings can do that :slight_smile:

Another advantage: It lets you compact the zip file after you’ve removed entries. No other zip lib can do that AFAIK.

It also provides an API that’s close to how FolderItem works, so transition should be easy. You can also read/write to the zip directly from/to Strings, i.e. no need to first have them as files on the disk.

All here: http://www.tempel.org/RB/ZipPackage

Also note this: https://forum.xojo.com/59129-ttszippackage/0