Re: getstyle cannot create target file

Hi,

 > There were recent patches touching these path creation routines
> that could very well have introduced odd behavior.
>
> Just do a:
>
> git log util/getstyle.c
>
> to see that there were patches touching these precise areas.

Yeah, the one I mentioned was the only one that looked odd to me. 
However, it was clearly the right thing to do, all that system()-based 
stuff was clunky and had to go. I'll try to confirm this hunch tomorrow 
just to be sure.

If that turns out to be wrong, I'll try to locally revert the odder 
commits to getstyle.c, too, before patching things. They aren't too 
many. Maybe the bug was inconspicuously introduced by a more trivial 
patch that can be reverted without causing much harm, or fixed more easily.

>
>> It seems to me that a much cleaner solution is to relocate
>> /long/path/to/file.png to themeDir/assets/file.png. The only problem
>> this seems to have is that a theme creator may use files with the
>> same name, but located in different places, and getstyle would
>> either have to rename these automatically (not too difficult) or
>> bork and warn the user (trivial, but possibly annoying to use).

> If you're copying the files to themeDir/assets then why is this
> a problem for getstyle? Why would it care about other files elsewhere?
> Note that I haven't read the code, so this is just a "common sense"
> type of question.

If the theme uses a pixmap at /home/user/Documents/brushedmetal.png and 
a background image at /home/user/Pictures/wallpapers/brushedmetal.png, 
relocating them with their full path under themeDir/, as 
themeDir/home/user/Documents/brushedmetal.png and 
themeDir/home/user/Pictures/wallpapers/brushedmetal.png will be fine.

However, trying to blindly relocate them to 
themeDir/assets/brushedmetal.png won't do. They may have the same name, 
but that doesn't mean they're necessarily the same file (one may be a 
small 64x64 px tile, the other may be a wallpaper), so overwriting one 
with the other is not the correct choice. getstyle should either fix 
this automatically (by renaming one of the files after the relocation) 
or complain about it.

It's the only likely reason I can think of for relocating files with 
full path (I have done it in the past, too, just in order to not 
recursively mkdir stuff). It is, however, a very remote cornercase; in 
fact, I doubt it's being handled correctly right now, too, as I don't 
see how findCopyFile could discriminate between two identically-named 
files at different paths; since that seems to have worked fine for 6-12 
years now, it's fair to conclude that it's woefully uncommon.

Alex


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