[AndyL]

My phone has just updated to Android 6 and I have had similar problems. I had set the storage location to be /sdcard/SheetPro. After the update MSPro couldn't read any of the PDFs in that directory. It said it couldn't find /storage/emulated/0/SheetPro/file.pdf

I tried doing a backup, but It looks like none of the PDFs were put in the backup. I then tried re-installing MSPro and restoring that backup. I selected use original location and unticked the delete everything option. This resulted in the same as before I re-installed. I then restored a backup from before the Android update and that has restored everything and used the SheetPro directory. If I select the storage location in settings it says /storage/emulated/0/SheetPro, which seems to be the same as before.

If I restore the "empty" backup it seems to be using /storage/emulated/legacy/SheetPro. So there seems to be some confusion over where it is looking.

This is really for information in case Mike can spot anything and do something to help others. I've got things back working as I want them. So I'm not after any help at the moment.

Also when I open any of the import/restore filer windows I get a popup saying "can't open Download" and the window shows /Root. I then have to click on sdcard and Download to get to the download directory. It would be nice to get this "fixed".

If there is any more information I can give that would be useful, let me know.

Regards

Andy

[BRX]

The real problems occur when you have the database on the sd card. But I can really recommend Johan's Perl program again. It was a “lifesaver“.

[itsme]

for "Johan's Perl program" see https://github.com/sciurius/MSPro-Tools

[BRX]

I have used the "path correction" utility a few times already because of Marshmallow updates and syncing the database to another device. Mostly it works fine and is a big help.

But I just noticed a few instances it messes with my database.

First it's case sensitive. I think it should be case insensitive. For some reason I don't know anymore a filename had changed from capital letters to small ones and MSP wasn't able to find and adjust the path, neither automatic nor manually.

The other one is sneaky. I had a couple of instances where the wrong file was adjusted because of the same file name. I have several files with the same name albeit in different directories. My guess is your utility just looks for the first occurrence and replaces the path for that. Could you implement another check if the directory is the same before you adjust the path for it and search further for a hit if it isn't? (Won't help me for wrong associations I have now in my database but would be nice for the future).

[Zubersoft]

Are we talking about the "Fix Broken File Paths" option that I added? File paths in Android are case sensitive, so I can't just treat them as case insensitive. It's perfectly valid to have two files with the same name but different case letters. Calls into the Android framework would fail if the case is wrong. On Windows 10, I could consider handling this differently though.

I'll see what I can do about the second part.

UPDATE:
I've changed the logic so that it tries to find the file whose path has the most matching characters at the end. Hopefully this will eliminate the problem you described.

[Zubersoft]

As a side note, you could have turned on the "confirm each" checkbox and picked which files were correct. If this list wasn't huge, this would have eliminated the problem also.

[BRX]

> I've changed the logic so that it tries to find the file whose path has the most matching characters at the end. Hopefully this will eliminate the problem you described.

Yes, I think that's a good solution.

> It's perfectly valid to have two files with the same name but different case letters. Calls into the Android framework would fail if the case is wrong.

O.K., I have to solve that on my side of things. I'm syncing often with my Windows directories and have to watch out for the case sensitive stuff when I'm changing something.

But, am I right that your utility only fixes paths if it has found a file? At least if I'm using the manual replacement of the path, shouldn't there all links pointing to the old SD-card path be replaced, regardless if they point to a file or not?
It seems to me that isn't the case currently. And it would be much easier to just replace a missing file on the card or change the spelling to fix the missing file and not to have to run the path adjustment once again.

[Zubersoft]

If you use a manual replacement, it will just use a database query to replace any matching value with the value you provide.