File Meta Data

I’m using a SQLite database where the user has the option of encrypting it. The client wants to have a password hint somewhere and have it travel with the file. The only thing I can think of put some metadata in the file itself.

On Mac OS X I could use the File Comments and stash the hint in there. Not ideal but it works.

In Windows I was thinking about using the File Details section (right click on a file in Explorer and look at the Details tab). I’m not finding anything that lets me define those Details. Anyone done this? I’m not seeing anything in WFS or MBS to set this information.

I’m open for other suggestions/ideas. Thanks!

Hi Bob,

If this is just a hint, add a Hint Table where you store it as the only Record / Field.

How about using extended attributes?

you could add data to the OS X file. (maybe Windows, too)

or just put an extra file next to the db file.
or put hint in a global preferences file.

Metadata is NOT x-platform and will get nuked if you move the db from OS X to Window or Linux
If you stick it in a file next to the db then it doesn’t “go with the file” unless they make sure to do that
An entry in a prefs file has the same issue unless they copy the preferences
Writing it as a header on the DB file has issues (you have to then extract the db from the file so you can get sqlite to read the db and gawd forbid your app crash or something & leave things in a bizarre state)
Writing it to the end of the file has issues in that it will get nuked if sqlite grows the db
A forked file would be nice but that too will get zapped if your move from platform to platform despite OS X and Windows having support for them

The only reason I’ve looked into this - <>
Short of shoving it IN the project file (which then means I have to open & read every project file to find this) there’s no nice cross platform answer :frowning:

on the Mac it is possible for applications to have packages as file format. The „file“ of an application is actually a folder (for Example a Keynote file is a Folder with the ending „.key“). If your app would use such a package-file-format, then the database could be in the package/folder and it could be encrypted. Also in the package/folder you could store a xml or text file with the password hint.
Moving the file means moving the whole package/folder, so the database and the hint always are together.
I do not know if windows also support such file formats.

[quote=283920:@Christian Mézes]
I do not know if windows also support such file formats.[/quote]
HA ! I wish
The only real option on Windows that I know of is to do like MS has done with the docx, xlsx etc formats where they are zip files containing many files as a single unit

Well, I (and the client) can live without it being cross platform. These files are going to be extremely personal in nature so the likelihood of them going from Mac to Windows or visa versa is limited.

I wish Windows had the bundle concept. It would sure make life easier. But, since they don’t it’s not worth crying about it.

I will look into the extended attributes.

[quote=283905:@Christian Schmitz]How about using extended attributes?

you could add data to the OS X file. (maybe Windows, too)[/quote]
This looks like it’s Mac OS X only? What about the Windows side?

Windows has the notion of file personal information but it mainly lists the owner and the name of the computer, copyright, resolution for pictures…

There is little documentation about that, though.

The MVP response here pretty much sums it up :

Let me check. I think I can just a new class for Windows.

@Bob Keeney
I added a class and a few methods and sent you an example with newer plugins by email.
Please try.

[quote=283894:@Emile Schwarz]Hi Bob,

If this is just a hint, add a Hint Table where you store it as the only Record / Field.[/quote]
I would go with this option, it’s x-plat and totally safe when transporting the file.

File meta data can be a nightmare, if the user copies the file to a non-fully supported disk, the meta data will dissapear. Also it can be removed by OS level tools and some OS X copy operations completely ignore it. Not to mention that if the user ever swaps platform, it’ll be gone.

Guys, how can an encrypted database have an unencrypted hint table?

The idea with using extended attributes (Mac/Linux) and your own file stream (Windows) allows the file to have the data until it’s emailed or archived without it.
But as long as it stays on disk or is just moved, it should be fine.

It can; just not easily. Rather than applying encryption to the entire database, you only encrypt the data when written to the DB and decrypt when reading.

Do Xojo’s database functions work with the old virtual volumes (do virtual volumes work even)?

The other way would be to use a binary stream and append the hint to the end of the SQL file once you’ve closed it and read it before you open the SQL file.

We use this technique to create files with a Quicklook preview (write out preview image data, then add our data on the end, it requires that you also set the Conforms To be “public.image”).

public image limited ?


Xojo’s Database nowadays is SQLite.
And it doesn’t use virtual volumes any more.

I’ve worked with virtual volumes in the past. Major, MAJOR pita to work with.

I just don’t see myself going down this route for a variety of reasons. So how do you actually query the database then if all the data is encrypted?

This might sound silly- but if putting the hint in the file properties is OK, then why not just put the hint in some fashion in part of the filename itself? The name is just another part of the file data in exactly the same, wide open user-space as the other properties…

We are treating the database file as a document so they can be opened and passed around. Personally, I don’t want to do a password hint: we force them to input it twice and do a warning that we can’t recover their file if they forget. But the client wants me to investigate if we can do it.

We can’t put it in the database itself because it’s encrypted. On Mac OS X I could potentially create a bundle and store it in there but that doesn’t solve Windows.

So the thought of using a file attribute becomes more appealing even if it’s not cross-platform. Not sure that having a file name like “Bob’s Document-my voice is my password” is going to fly.

In the long run, if I push back saying it’s not easily doable they’ll be okay with it. I can at least say that I tried.

Christian sent me a new plugin to try so it might be ‘good enough’.