[BRX]

This is maybe a stupid question so I'm not requesting but only asking:

Is it possible to include the path to the MSP folder (managing my own files) to either the Android and the W10 path/folder in the database?
Like so you have a secondary entry for the path on the respective entry in the options after the main folder location on the device.

Mike, I know you're working on future syncing features anyway.

For the time being I'd like to "sync" my database between the devices by copying the *.db files and I'm asking myself if including "the other path" already in the database might spare me/us the editing of the file paths with a sql editor or Sciiurius' tools or the find missing files feature when one copies the database from one device to another with different OS.

Probably much more complicated than I'm thinking with many problems more I can't even imagine. But maybe not, so I'm asking if this might be some feature for your customers who bought MSP for Android as well as for W10 and like to keep them in sync.

[Zubersoft]

One of the changes I want to make is to make all file paths relative to the storage location (unless files are not being managed by MobileSheetsPro, in which case the full path must be saved). Once I do this, in theory you could easily copy your database between versions, because the storage location isn't stored in the database, and all of the files would be relative to whatever location you've picked on each OS. Until this is done, just storing the storage location in the database isn't enough, because the full path to every file is still stored in the database and has to be updated (which is what happens when you restore a backup file). The real hope is that the upcoming sync features will make it easy enough for people to sync up changes that they won't need to mess with copying things between devices.

Mike

[sciurius]

Did you ever get to implementing this relative paths feature?
It would solve a major problem I'm currently facing...

[Zubersoft]

Not yet I'm afraid. These changes are going to ripple across the entire application and cause database changes, so I haven't started working on it yet. I was thinking of tackling it around the same time that I add support for multiple libraries/databases.

Mike

[sciurius]

Okay, I'll work my way around somehow...
Thanks.

[sciurius]

These changes are going to ripple across the entire application and cause database changes,

Actually, I would be surprised.

There should be just a couple of places in the code where paths are fetched from and stored into the database.
When retrieving a path that is relative, prepend the storage location. When storing a path that starts with the storage location, strip it off.

I can't imagine it would be more complex.

[Zubersoft]

The problem is that I can't assume every path is relative to the storage location, as users can add files from anywhere if MobileSheets isn't managing their files. Even if MS is managing the files, they can still add audio files from other locations. So I also have to store whether it's relative or absolute. The code that retrieves or writes the path to the database can then determine whether or not it needs to prepend the path with the current storage location. I'll have to spend some more time doing analysis on this before I assume it's as simple as just updating the database code though.  Things always seem like they should be simple, but then when you start doing the work, it rarely is.

Mike

[BRX]

Well, it would simplify it IMO if you use relative paths at least for the files in the MSP storage location and absolut paths only if they are from other places by adding or audio.

I know we discussed this a few times. Personally I decided now to put all my files (including audio) under the MSP storage location (excluding a few GB of big audio files from syncing with dropbox, so I have to sync and maintain them manually). So I'm all for relative paths like that.

Am I correct to resume, that with all files in the storage location such (and only) relative paths the database would be interchangeable between Android and W10 devices?
I think that would be great for a simple and less time consuming sync (or manually copying of the database between devices).

I think after having set up MSP with the files in the beginning usually there will be many more changes in the database only (setlists, annotations etc.) than changes that require adding or changing sheet and audio files (at least for me since I added most of my PDFs I need or might need when I got MSP and my tablet). So I'm all for the possibilty just to "copy the database" over without touching the other files.

I know your concerns about unexperienced users and orphaned files. But MSP is such a complex and mighty tool I think it warrants some options and possibilities for advanced users who know what they're doing (or believe it and take the risk).

[sciurius]

So I also have to store whether it's relative or absolute.

AFAIK, for all platforms you can reliably determine whether the path is relative or absolute by inspecting the filename. In the Linux/Android case this is whether the filename starts with a slash. I'm sure Windows has similar ways.

If a user stores filenames in the database that are not relative to the MSPro storage location, she creates a non-portable library and must be prepared to face consequences when exchanging the library with other devices.

BTW I don't think "Manage my files" is related to being MSPro storage location relative. I can (and do) instruct MSPro to not manage my files, and still have all of them under the MSPro storage location. Just like BRX described.

[Zubersoft]

I can give it a try to just convert existing paths in the database to relative paths and then update the database code. There is some existing code that uses a "LIKE" query in the database when trying to look for matching files. If I'm currently passing an absolute path, that would obviously be an issue, and I would need to convert to relative if needed before executing the query. There may be other examples of situations like that where I try to find matches in the database for paths that need to be updated.

BRX - even with relative paths, Windows uses backslashes while linux requires forward slashes. Windows seems to be able to tolerate forward slashes (I think), but I wouldn't trust Microsoft's entire API to gracefully handle that. I know for a number of things, I've had to write my own methods instead of using Microsoft's because theirs would throw an exception or not work correctly if given an Android path. Android would not be able to use Windows paths at all.  While I could update the database code that reads out the paths to "sanitize" them and fix slashes if necessary, the problem is that queries in the database to look for matching paths would fail due to the slashes being different. A simple script or program could be written to adjust the relative paths in the database to use the correct slashes (like other things Johan has produced), so that could be one option for advanced users who want to operate that way.

Mike

[Zubersoft]

One interesting thing I could try is replacing slashes with wildcards before doing any database path comparisons. That could get past the problem. I could then add code to fix paths if necessary when read from the database although I don't know if there would be any noticeable performance hit at startup or other times all the paths are read due to the extra processing. I doubt it though as string manipulations are usually fairly quick on modern processors

[sciurius]

Yes, this is a common problem when dealing with Windows and real platforms.
Usually, the best bet is to go for the forward slash notation, since that seems to be generally accepted as being system agnostic (think URL, URI). According to the information I found on the net the java API should treat a slash on Windows as a backslash.
Did you experience otherwise?

[Zubersoft]

The Windows 10 version of MobileSheets is written using C# (UWP). File operations rely upon the System.IO namespace as well as their StorageFile/StorageFolder classes. Passing an Android path to a simple function such as System.IO.Path.GetFileName doesn't work at all (an exception is thrown I believe). That's just one example - there are a lot more. That's why I had to implement my own functions for a lot of those types of actions for any code that might encounter an Android path. For that reason, I don't trust any of the Windows APIs enough to correctly handle forward slashes, which is why I've stuck with regular Windows style paths with backslashes.

Mike

[Zubersoft]

As a side note, as part of the move to relative paths, I could store them in the database with all forward slashes, and when I read them from the database, I'll switch them to backslashes.  Using your suggested approach, I'm already going to have to modify the paths when reading/writing, so I might as well do that too. Combined with my approach to ignore slashes when searching for files, this would allow the database to be moved freely between Windows and Android.

[BRX]

This would be great (and diminish my personal need for the rest of a MSP sync feature). Maybe you can integrate this as individual step (for advanced users) without additional syncs for files because it's of course more comfortable to sync directly with Wifi or BT between server and client.

I hoped to get around using Sciurius' tools or a SQL editor for adjusting Android databases for W10 and that would be it.

But on a related note: As I said I moved the Audio files under the MSP storage location which in my case is xxxx-xxxx/noten/Audio on Android (links working) and X:\dropbox\noten\audio
I backed up the database (without Audio files, all are already at the destination) from Android and restored on W10.

I expected the backup to respect the relative paths, but the restore on W10 resulted in links to X:\dropbox\noten
So there seems to be a problem with the adjusting of the audio files/links.