Does Fl_Image always release the lock on the file it is reading

[pvr...@btinternet.com]

I have noticed that I am not allowed to update a file after I've opened it with Fl_PNG_Image.

I use:

Fl_Image* image;

:

:

Fl_Image* raw_image = new Fl_PNG_Image(filename);

// calculate new image size after scaling to fit

image = raw_image->copy(new_w, new_h);

delete raw_image;

I have only a feeing this is happening. I just want to rule out that Fl_Image (or its heirs) is locking the file. Depending on the file extension, I use Fl_PNG_Image or JPG or BMF

Thanks Phil.

[lifeatt...@gmail.com]

FLTK 1.3 or 1.4?

Windows, Mac, or Linux?

Using the FLTK PNG code, or the system PNG library?

[lifeatt...@gmail.com]

Fl_Image doesn't have any link to the file or other resources. Fl_PNG_Image does an fopen() and a fclose().

So the following sequence (FLTK 1.4, Linux, installed PNG library) works:

    Fl_Image *img;
    Fl_Image *imgc;
   
    img = new Fl_PNG_Image("folder.png");
    imgc = img->copy(250, 250);
    delete img;
   
    FILE *imgF = fopen("folder.png", "wb");
    fputc(0, imgF);
    fclose(imgF);

The file which was opened by Fl_PNG_Image is successfully clobbered by the subsequent fopen/fputc.

[Philip Rose]

From: lifeatt...@gmail.com
Sent: 27 July 2022 15:07
To: fltk.general
Subject: [fltk.general] Re: Does Fl_Image always release the lock on the fileit is reading

--

 

 

Thanks,

 

I didn’t think it would be a problem. I’ll need to look elsewhere if it happens again.

 

I am running on W10 using the libraries from fltk. FLTK 1.4.

 

Phil.

[Greg Ercolano]

On 7/26/22 07:59, 'pvr...@btinternet.com' via fltk.general wrote:

I have noticed that I am not allowed to update a file after I've opened it with Fl_PNG_Image.

    Are you certain it's not another process/program holding the file open?

    This sounds like Windows; I've noticed when editing images if I have things
    like image browsers/previews or sometimes even folder browsers open, I
    find I have to close them before I can update the image e.g. from a paint
    program.

    So try closing all apps/windows/browsers except your image editor
    and FLTK app.

    If it still acts like it's locked, and then closing the FLTK app makes it
    work again, let us know, as that would be a sure sign something is wrong.
    (Also make sure your own app isn't doing an fopen() on the file and leaving
    it un-closed during your image write)

    Small Windows/WIN32 digression:

    FLTK's png library internally uses fopen()/fclose(), and would appear from the
    code to be doing this correctly (at least in 1.4.x), opening the file only briefly
    to load it into memory.

    Once fclose() is called, any "write lock" (described below) should disappear.

    While FLTK does not use 'file locking', it does use fopen(), and IIRC
    under Windows a file opened for read with fopen() will prevent other
    processes from writing, due to the C library's implementation of the
    fopen() function, which I imagine is just implemented as a call to the WIN32
    CreateFile() function, which has the concept of FILE_SHARE_XXX flags.

    I believe the fopen() wrapper /probably/ passes 0 for the 'file share'
    parameter which blocks writing of the file while fopen'ed for read
    (you get "A sharing violation occurred" from other programs)
    which is something of a 'file lock'.

    But that would only be a problem if the file remained open, and from what I
    can tell, FLTK fopen()'s the file, reads it, then fclose()'s it again, so it should
    not remain locked after the file was loaded into memory.

    I'm guessing some other app has the file open, like a browser or image
    previewer, or some such.