Re: getstyle cannot create target file

On Wed, 20 Apr 2016 at 22:52:32 +0300, Alexandru Lazar wrote:
> Good evening everyone,
> 
> This took a little longer than expected because something felt a
> little off in what was happening (see the P.S. below). The patch I'm
> attaching implements the "clean" fix I proposed in this thread. It
> relocates assets under <themedir>/assetname.
> 
> The changes are in two functions:
> 
> 1. In findCopyFile, it does wcopy_file(dir, fullPath, file) instead
> of wcopy_file(dir, fullPath, fullPath) (where dir is really
> <themedir>, fullPath is <full path to file>/file, and file is the
> file's name, without the rest of the path). This causes file to be
> copied at <themedir>/file, not <themedir>/fullPath.
> 
> 2. On the *other* branches in makeThemePack (i.e. when
> strrchr(WMGetFromPLString(file), '/') doesn't return null, which
> causes findCopyFile to be called because the full path to the file
> is not known), makeThemePack now gets the "new" path before copying
> the file, and then calls wcopy_file with the new path as a
> destination.
> 
> I have tested this patch on my system as well as I could, but I
> would appreciate any additional testing. Needless to say, any
> comments are appreciated, too.
> 
> While testing, I did stumble upon something that appears to be an
> unrelated bug. I'm not reporting it separately because I'd
> appreciate another opinion on it (maybe my patch introduces it in
> some manner that escapes me).
> 
> If I save a theme, apply it (causing the assets to be loaded from
> the .themed directory, rather than from wherever they're on my
> system), then gestyle -p again, it doesn't work. wcopy_file borks
> like this:
> 
> WINGs(wcopy_file(findfile.c:441)): error: Could not open input file
> "~/GNUstep/Library/WindowMaker/Themes/test.themed/BlueImage.jpeg":
> No such file or directory
> 
> The file *does* exist, so the obvious culprit is that ~ doesn't get
> expanded to /home/alazar, but I don't understand is why
> WMGetFromPLString(file) would return a path that begins with "~" in
> the first place. I suspect this problem did not occur back when
> copying was done via system() because the shell was expanding the
> "~", but that's no longer the case. Besides, the "dirty" fix
> (mkdir-ing the whole hierarchy before wcopy_file) would not have
> avoided this, either.
> 
> Can anyone find something wrong with this reasoning?
> 
> If not. I'll provide a separate patch for this problem.

I believe you are correct in saying that the problem is the ~ in
the path.

I will apply your patch now and wait for the other fix, thanks!


-- 
To unsubscribe, send mail to [email protected].