1
0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-10 01:48:00 +00:00

Better file-existence test on Windows.

Windows, annoyingly, doesn't seem to have any bit flag in
GetFileAttributes which distinguishes a regular file (which can be
truncated destructively) from a named pipe (which can't).

Fortunately, I'm saved from needing one by the policy I came up with
in the previous commit, in which I don't bother to ask about
truncating a file if it already has zero length, because it would make
no difference anyway. Named pipes do show up as zero-length in
GetFileAttributesEx, so they get treated like zero-length regular
files by this change and it's all good.
This commit is contained in:
Simon Tatham 2018-02-07 20:05:32 +00:00
parent b4fde270c6
commit 6c4d3cb8f3

View File

@ -590,11 +590,33 @@ FontSpec *fontspec_deserialise(void *vdata, int maxsize, int *used)
int open_for_write_would_lose_data(const Filename *fn)
{
FILE *fp;
if ((fp = f_open(fn, "r", FALSE)) != NULL) {
fclose(fp);
return TRUE;
} else {
WIN32_FILE_ATTRIBUTE_DATA attrs;
if (!GetFileAttributesEx(fn->path, GetFileExInfoStandard, &attrs)) {
/*
* Generally, if we don't identify a specific reason why we
* should return true from this function, we return false, and
* let the subsequent attempt to open the file for real give a
* more useful error message.
*/
return FALSE;
}
if (attrs.dwFileAttributes & (FILE_ATTRIBUTE_DEVICE |
FILE_ATTRIBUTE_DIRECTORY)) {
/*
* File is something other than an ordinary disk file, so
* opening it for writing will not cause truncation. (It may
* not _succeed_ either, but that's not our problem here!)
*/
return FALSE;
}
if (attrs.nFileSizeHigh == 0 && attrs.nFileSizeLow == 0) {
/*
* File is zero-length (or may be a named pipe, which
* dwFileAttributes can't tell apart from a regular file), so
* opening it for writing won't truncate any data away because
* there's nothing to truncate anyway.
*/
return FALSE;
}
return TRUE;
}