Screenshot and thumbnail not created in the same directory

[guijan]

Consider the following invocation:

scrot --thumb 10 /tmp/test.png

Scrot's execution would then be like this:

First, we'd end up on this line: https://github.com/resurrecting-open-source-projects/scrot/blob/f1b195fb8dc56f7dbc7f349bf3d0b2ba41e1af62/src/scrot.c#L158 The string filenameIM points to would be "/tmp/test.png"

A little further down, we'd end up on this line of code: https://github.com/resurrecting-open-source-projects/scrot/blob/f1b195fb8dc56f7dbc7f349bf3d0b2ba41e1af62/src/scrot.c#L190 The string filenameThumb points to would be "/tmp/test-thumb.png"

The bug here is that between those 2 lines of code, /tmp/ could be changed to point to a different directory.

The solution should be to chdir() to the output file's directory, then handle the output file and thumbnail file as basenames only. This also has the nice side effect of allowing the creation of output files with longer filenames: as the code currently stands, with a PATH_MAX of 4096 as is typical these days, if the directory portion of the filename alone is 4000 bytes, we may be unable to create a file with a basename over 95 bytes (+ 1 byte reserved for the '\0') even though X/Open guarantees NAME_MAX is at least 255.

[N-R-K]

I just realized that the scrotCheckIfOverwriteFile thing also applies to the thumbnail.

So if user does scrot -t16 shot.png and shot.png didn't exist but shot-thumb.png did, then it'll write the thumbnail to shot-thumb_000.png instead.

I suppose that "works", but I'm not sure if that's intuitive or not. At the very least, we should probably document the behavior.