creates C:\FLTK\fltk.org\fltk.prefs / ~/.fltk/fltk.org/fltk.prefs

[ricary37]

Describe the bug
vncviewer64.exe creates C:\FLTK\fltk.org\fltk.prefs

To Reproduce
Steps to reproduce the behavior:
run vncviewer64.exe

Expected behavior
no any additional files in root created

Screenshots
n/a

Client (please complete the following information):

• OS: Windows 10 x64
• VNC client: TigerVNC
• VNC client version: 1.9.0
• Client downloaded from: github

Server (please complete the following information):

• OS: debian
• VNC server: TigerVNC
• VNC server version: 1.9.0
• Server downloaded from: github
• Server was started using: vncserver

Additional context
n/a

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[samhed]

I can't reproduce your problem. I have tested vncviewer64.exe version 1.9.0 on both Windows 10 and Windows 2008 R2.

[CendioOssman]

Perhaps you weren't allowed to create those directories on your test machine?

Anyway, I can see this path from the FLTK library. However it is only supposed to read this file, never create it.

@bphinz, what version of FLTK do you have in your build system? Any patches?

[bphinz]

Either 1.3.3 or 1.3.4-2, with no additional patches. I'll check later and confirm.

[samhed]

I tested again and ensured that I was allowed to create directories under C:\ with the same user as was running the vncviewer. So, the fact stands - I can't reproduce this

[ricary37]

i can add that i run vncviewer.exe from c:\test1\test2 and i execute it as "user" (not administrator).

[CendioOssman]

I've also tried to reproduce this and failed.

How are you starting vncviewer? Just double clicking the file in an explorer window?

[ricary37]

Here is step by step guide how to reproduce the bug:

1. run cmd.exe, then type:

c:
cd \
mkdir 1
cd 1
net user /add 1 1

2. download vncviewer64-1.9.0.exe and put into c:\1

3. download PsTools from Microsoft.com, upack PsExec64.exe and put it into c:\1

4. run cmd.exe, then type:

c:
cd \1
PsExec64.exe -u 1 -p 1 vncviewer64-1.9.0.exe

5. when vncviewer window appears, click Options button, then close the application

6. Now you can see the newly created file: C:\FLTK\fltk.org\fltk.prefs

[samhed]

Yes, with those instructions I can reproduce this and get the behavior you are seeing.

[bphinz]

I wonder if this behavior is specific to our application or if all FLTK based apps do this when run from PsExec?

On Wed, May 15, 2019 at 8:11 PM Samuel Mannehed ***@***.***> wrote: Yes, with those instructions I can reproduce this and get the behavior you are seeing. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#822?email_source=notifications&email_token=AB45M3K6322TCOR65NJRSBLPVSRCDA5CNFSM4HFYAEZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVQJFLI#issuecomment-492868269>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB45M3LXK3VV4IHVDENVOY3PVSRCDANCNFSM4HFYAEZQ> .

-- Sent from Gmail Mobile

[CendioOssman]

I would guess that it is general. But we might want to debug it more to confirm that, and then report it to FLTK.

[ricary37]

gmsh uses fltk, but doesn't have the bug

[CendioOssman]

I've tried the above instructions on two different machines without being able to reproduce this. Either this depends heavily on something specific to the machine, or there is something omitted from those instructions.

There won't be any progress if we can't reproduce this properly. :/

[CendioOssman]

Ah. I actually did reproduce it. The file just ended up in a different place than for you.

So I debugged this and it is unfortunately a FLTK bug. Some widgets like to check for FLTK "options". I assume this was only meant to read this file, but unfortunately the code has been structured in a way that also results in it writing the file back (or at least attempting to).

I don't think we have time to fix up a patch for them right now, so I'm afraid I'll have to point you to filing a bug with the FLTK project. Feel free to link it here though so we can track it.

[Albrecht-S]

Just to be sure: does this manifest in FLTK 1.4 as well? Can you build TigerVNC with FLTK 1.4?

I remember that something related to marking Fl_Preferences dirty has been fixed in FLTK 1.4, particularly in commits 7542e8cb1 and a8f4fbc2e.

These commits have not been backported to the 1.3 branch AFAICT.

Can you try if these patches would fix the issue for you? If yes we might backport them to 1.3 (Git only, there is currently no further release plan for the 1.3 branch).

[CendioOssman]

I have not tried 1.4, no. Is it API compatible with 1.3.5?

I'm afraid I'm a bit swamped right now, but if someone else have time to do a test build then that would be very helpful.

[Albrecht-S]

Yes, FLTK 1.4 is API compatible with 1.3.5.

There are a few cases though where you'll have to #include another FLTK header where 1.3 worked w/o this header because it was included by some other FLTK header by accident (i.e. unintentionally). One example would be to #include <FL/x.H> to use fl_xid and similar issues. But if your code is complete WRT including the necessary headers it should work with both FLTK 1.3.5 and FLTK 1.4.

Side note: FL/x.H has been replaced by FL/platform.H in FLTK 1.4 but both 1.3.5 and 1.4 have compatibility headers so that you can use either in FLTK 1.3.5 or later (but not 1.3.4 or earlier). If you're targeting 1.3.5 or later you could replace FL/x.H with FL/platform.H in your code.

Another question: what was (is) the contents of fltk.prefs in your reproducer mentioned above? This could help us to track the issue down. Maybe we could create a small reproducer/demo program...

[Albrecht-S]

FYI: I was able to build vncviewer under Linux Mint 19.1 with FLTK 1.4 with a very small patch (I had to include FL/x.H in two files as assumed in my previous comment). I also had to add the png and dl libs to the linker command for whatever reason, see attached patch:

fltk-1.4.diff.txt (git diff)

Note: This is only a proof of concept for building with FLTK 1.4. I could not test anything else because I don't have a running vnc server.

Feel free to use the patch, at least for the source files. This should be fine for any version of 1.3 and 1.4 as well.

[Albrecht-S]

FTR: I found a simple reproducer, see my comment here.

[samhed]

Thanks for looking at this @Albrecht-S. So the gist is that this is still a problem in FLTK 1.4?

[Albrecht-S]

Yes, it is. Basically it's not a bug - it's by design. Unfortunately there's no simple solution to suppress this.

The reproducer in vncviewer mentioned above was to click on "Options..." and this results in fltk.prefs being created. Another reproducer is to click on "Load..." which creates filechooser.prefs when running the built-in file chooser. This is because FLTK stores options and user preferences (per user and system wide) in files. Under Linux this is (a) in /etc/fltk and (b) in the user's home directory. Windows has different storage conventions but it's similar. The following is from my Linux system in my home folder after running tigervnc (vncviewer) and clicking on both Options and Load:

$ tree .fltk
.fltk
└── fltk.org
    ├── filechooser.prefs
    └── fltk.prefs

It's hard to say how to do this w/o touching files, but we're discussing it. One idea would be to disable all options and preference writing to files on request by calling a function or setting a global variable in the init code of the program. Or something like that. The problem is that programs may want to write their own preferences (FLTK: Fl_Preferences) to files...

[Albrecht-S]

Note: there is now a fix for this issue in in FLTK 1.4 (Git commit c0237a1) which should allow you to disable file access when FLTK reads its options. Online documentation will be updated shortly.

(Update: FLTK 1.4 online documentation has been updated.)

There are currently no plans to backport this to FLTK 1.3 though.

See also this comment and surrounding comments.

[CendioOssman]

Great. Any idea when 1.4.0 might be out? We probably won't look at using a newer FLTK until then.

[Albrecht-S]

Sorry, there is no schedule for a release of FLTK 1.4.0 right now.

[CendioOssman]

Note that this seems to happen on Unix as well, in ~/.fltk/fltk.org/fltk.prefs.

[Albrecht-S]

FYI: This is all fixed in FLTK 1.4.0, we're working on the release right now. Currently I'd guess that there are chances to make the final release during May 2022. New features regarding this issue in FLTK 1.4 are:

• disable writing prefs, see Fl_Preferences::file_access
• new default preferences folder on Windows to avoid writing to C:\FLTK
• new default preferences folder on Linux, honoring the XDG conventions

For further information on the default folder and file conventions please see the full documentation of Fl_Preferences.