geoffmcl
commented
6 years ago @thvv wow what an interesting discovery...
It seems it is not only on the MAC, but is the same in unix/linux, and Windows, using current tidy 5.7.3...
I just set a file to 444 - $ chmod 0444 temp.html, and then $ tidy temp.html and I get Document: "temp.html" is not a file! - Zute, or as Snagglepuss would say Heavens to Murgatroyd!!!
It certainly seems at least one write bit must be set, like $ chmod 0644, and tidy will be ok...
On the face of it this does not seem right. Provided you are not using the -modify option, which will try to overwite the file, it seems only read permission should be required...
AH HA! The answer is simple. The tidyDocParseFile service has the following code -
int status = -ENOENT;
FILE* fin = fopen( filnam, "r+" );
if ( !fin )
{
TY_(ReportFileError)( doc, filnam, FILE_NOT_FILE );
return status;
}
fclose( fin );Now reading some fopen references that access string "r+" means **read/update**: Open a file for update (both for input and output). The file must exist.
And note that if I set the file read only in Windows, > attrib +R temp.html, tidy will fail at the same place...
Now after that code block, WIN32 and UNIX separate...
UNIX continues with fin = fopen( filnam, "rb" );... you will note the + has been removed...
Windows goes another code path, using in essence -
HANDLE fp = CreateFileA( filnam, GENERIC_READ, FILE_SHARE_READ, NULL,
OPEN_EXISTING, 0, NULL );
...
fin->map = CreateFileMapping( fp, NULL, PAGE_READONLY, 0, 0, NULL );
...
data->view = MapViewOfFile( data->map, FILE_MAP_READ,
(DWORD)( data->pos >> 32 ),
(DWORD)data->pos, numb );So we note also in Windows, that the concept of + is not required, with GENERIC_READ, PAGE_READONLY, and FILE_MAP_READ... this of course needs to be verified...
Reading this far, maybe, just maybe! there is a good case for removing that initial + also... but as I review the history, maybe NOT...
It should be noted that the above fopen( filnam, "r+" ); block was added relatively recently.. I trace it back to commit ce105dcf09, May 7, 2017... It was to address #391 - the fact that a directory would be treated as a file in unix/MAC...
And IIRC a fopen( dirname, "r" ); will succeed in unix - need to check this...
Maybe the whole block could be replaced with a crossported stat check, which would also yield the size and time, which would make some of the subsequent code both in windows and unix redundant...
I have been using the following, well tested, crossported service, in many projects, for a long time -
#ifdef WIN32
#define M_IS_DIR _S_IFDIR
#else // !WIN32
#define M_IS_DIR S_IFDIR
#endif
static struct stat buf;
enum DiskType {
MDT_NONE,
MDT_FILE,
MDT_DIR
};
static DiskType is_file_or_directory(const char * path)
{
if (!path)
return MDT_NONE;
if (stat(path, &buf) == 0)
{
if (buf.st_mode & M_IS_DIR)
return MDT_DIR;
else
return MDT_FILE;
}
return MDT_NONE;
}
static size_t get_last_file_size() { return buf.st_size; }
static time_t get_last_file_time() { return buf.st_mtime; }It seems this is a bug. Tidy should NOT have a problem with a read only files.
If the -modify option is used, then this problem should be handled at the output stage...
In any case tidy should not report is not a file! when it is a file...
What do others think... thanks...
i-give-up
jidanni
relphj
thvv
I check files before install with tidy --markup no --quiet yes --show-warnings no index.html I get the error Document: "index.html" is not a file! well, it certainly is. But it is mode 444. Which is fine because I am not updating it, just checking it. Changing the file mode to 666 makes it work.
I installed this version from macports tidy-5.6.0_0.darwin_16.x86_64.tbz2