| | [ Return to Bugs & Features | SVN ⇄ GIT ]
STR #2034
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 3 - Moderate, e.g. unable to compile the software |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | Core Library |
|---|
| Summary: | function Fl_Preferences::getUserdataPath() creates wrong directories |
|---|
| Version: | 1.4-feature |
|---|
| Created By: | popej |
|---|
| Assigned To: | matt |
|---|
| Fix Version: | 1.4-current (SVN: v12299) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
No files
Trouble Report Comments:
| |
| #1 | popej
05:32 Sep 03, 2008 |
| Function Fl_Preferences::getUserdataPath() generates wrong directories, when filename contains a dot. I think the error is in RootNode::getPath,
where function search for '.' instead of '/'.
// get the path to the preferences directory
char Fl_Preferences::RootNode::getPath( char *path, int pathlen )
{
strlcpy( path, filename_, pathlen);
char *s;
for ( s = path; *s; s++ ) if ( *s == '\\' ) *s = '/';
s = strrchr( path, '.' ); // <== should be strrchr(path, '/')
if ( !s ) return 0;
*s = 0;
char ret = makePath( path );
strcpy( s, "/" );
return ret;
} | |
| |
| #2 | matt
13:38 Oct 18, 2008 |
| Actually, the code is correct. The naming of this function is bad though, plus the whole class should be private to begin with (which is why I keep this STR around in 1.3). getUserdataPath (which is the function that calls rott::getPath) is supposed to return a unique path for more data that is directly related to the .pref file. It does so by creating a directory with the same name sans the .prefs extension. | |
| |
| #3 | popej
15:49 Oct 18, 2008 |
| You are right. Unfortunatelly .pref extention is not obligatory. Consider following code:
Fl_Preferences *f;
char buffer[1000];
f = new Fl_Preferences("mypath.x/myfile", "application", NULL);
f->getUserdataPath(buffer, sizeof(buffer)); | |
| |
| #4 | matt
01:36 Oct 19, 2008 |
| If you use your own path and file for your preferences database, getUserdataPath() makes not much sense (since you know a path anyways).
This function was meant to be used with the more abstract constructor Fl_Prefrences(USER, vendor, application) which chooses a valid file and path for the preferences database for every host system.
I will try to either exclude the unsupported functionality or update the code accordingly. | |
| |
| #5 | popej
03:09 Oct 19, 2008 |
| After your explanation, I think the priority of this STR could be changed to LOW. | |
| |
| #6 | matt
09:23 Jul 07, 2017 |
| Fixed in Subversion repository.
In the unlikely case that the filename part of the preferences path has no file extension, the resulting directory will be the original path with ".data/" appended.
If there is no filename at all (which I would consider a bug), "data/" is appended.
Also, this fixes a possible buffer overflow. | |
[ Return to Bugs & Features ]
|
| |
