Use of paths from file picker causes failure of save operation

REPRODUCIBILITY (% or how often): 100%
BUILD ID = OS VERSION (Settings > About product):
HARDWARE (XA2, X10, X10 II, …): Volla phone GS290
REGRESSION: (compared to previous public release: Yes, No, ?): yes


I maintain/develope scribble. It utilizes a filepicker to obtain a path to save to:

Component {
    id: savePickerPage
    ImagePickerPage {
        onSelectedContentPropertiesChanged: {
            savePath = selectedContentProperties.filePath

which is used from a js function:

onClicked: {
               toolSaveVisible = false;
               idImage.grabToImage(function(image) {
                   image.saveToFile(  savePath + fileName + ".png" )

This worked in 3.4. It no longer works. I’m in the process of getting this sailjail conforming.


Create a ImagePickerPage to obtain a path.
Attempt to save to that path.


  1. Open scribble app
  2. Scribble
  3. Save the image
  4. Open gallery
  5. See that the image is ‘Oops, cannot display image’


Image saves. Gallery displays.


The file IS saved, but to /home/defaultuser (even after applying sailjail config). Push it from ~ to Pictures and the image can be displayed.


I’m guessing this has something to do with Standardpaths and Sailjail.

When debugging (with QML live feedback), if I initially set savepath like so:

property var savePath : StandardPaths.home + '/Pictures/'


     if (debug) console.debug(savePath)
       idImage.grabToImage(function(image) {
           image.saveToFile(  savePath + fileName + ".png" )


onClicked:885 - /home/defaultuser/Pictures/
onSelectedContentPropertiesChanged:82 - /home/defaultuser/Pictures/

And the picture saves to gallery (after the filepicker shows me the directory)

For now, I’ve just disabled the picker and save to ~/Pictures.

Sounds like your app is running outside of SailJail (launching from the SDK is unjailed), and the file gets picked up by Tracker, but is inaccessible to the jailed Gallery.
So technically nothing wrong, just confusing.

I thought surely something like this… but… the files were being saved in ‘/home/defaultuser’ … and the MediaIndexer flipped out. But, I had tried:

  1. exit app,
  2. start from launcher
  3. accept sailjail terms
  4. try saving

With the same result.

I can only recommend you double-check (on disk, tracker might indeed be upset).
If your jailed app can write to ~, even if just broken/empty files, that’s a serious problem…

You nailed it. It’s very odd. I just released a fixed version, so I have to revert to demonstrate. It’s

The really strange thing is that the thumb/preview will show in the cover action of the Gallery, but entering the Gallery, it gives you the oop message.

The image (png) in ~ is, however, just fine if you shove it into the Pictures folder (mv).

It’s kind of interesting.

1 Like

Get’s more weird.

  1. oops image can’t be removed in gallery (nor be seen)
  2. open same image in app that saved it … the data is there.

Ok. BUT, now I’ve reverted and deployed without QML live and it ‘just worked’. Quit, restart, accept Jail conditions and … it just works.

I don’t get it. I’m guessing it has to do with debugging with QML live. ? Ah, just guessing.

Sounds a lot like “launched from SDK”, i.e. not jailed.

It’s a poorly conceived idea :slight_smile: In any case it would need to be a more generic picker. For the time I’ve just set this to write to ~/Pictures.

In any case, the update I’ve released doesn’t suffer from any file corruption issues.

Just for reference how you can do this ‘cleanly’

Component {
    id: savePickerPage
    FilePickerPage {
        onSelectedContentPropertiesChanged: {
            var filePath = selectedContentProperties.filePath
            savePath = filePath.match(/(.*)[\/\\]/)[1]||''
            savePath = savePath + '/'

EDIT: and just to be absolutely clear, this was just buggy since it would have given you the filename of the selected file with the picker and saved a file with the provided attached at the end. Wonder why no one caught it yet. No users :slight_smile: Boo. Hoo. Well, I use it. I probably just never noticed the odd filenames. sigh.