WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
237477
Add null check for path in makeAllDirectories
https://bugs.webkit.org/show_bug.cgi?id=237477
Summary
Add null check for path in makeAllDirectories
Sihui Liu
Reported
2022-03-04 11:23:11 PST
...
Attachments
Patch
(2.88 KB, patch)
2022-03-04 11:30 PST
,
Sihui Liu
no flags
Details
Formatted Diff
Diff
Patch
(2.57 KB, patch)
2022-03-04 16:46 PST
,
Sihui Liu
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Sihui Liu
Comment 1
2022-03-04 11:30:39 PST
Created
attachment 453859
[details]
Patch
Chris Dumez
Comment 2
2022-03-04 14:30:06 PST
Comment on
attachment 453859
[details]
Patch Your test is failing on api-gtk.
Darin Adler
Comment 3
2022-03-04 15:10:10 PST
Comment on
attachment 453859
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=453859&action=review
> Source/WTF/wtf/posix/FileSystemPOSIX.cpp:280 > + LOG_ERROR("File failed to access. Error message: %s", safeStrerror(errno).data());
I think "file failed to access" is a vague message to put in a log, and not how I would describe a failure of the access function. If we are going to log this, then the message should make some mention of the fact that were were attempting to create directories, perhaps. Also wondering why we decided to log about the failure of this access call but not about the failures of the other access and mkdir calls below. Generally we want these file system abstraction functions like makeAllDirectories to not log directly to the console, so callers can make calls they know will or might fail without unconditionally cluttering logs. I understand that this conflicts with the desire to know what’s happening when diagnosing a bug. I’m not sure there is an easy answer. Generally speaking it would not be good if all file system calls logged what happened directly to the console, and certainly that’s not how the underlying POSIX functions behave.
Sihui Liu
Comment 4
2022-03-04 16:32:18 PST
Comment on
attachment 453859
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=453859&action=review
>> Source/WTF/wtf/posix/FileSystemPOSIX.cpp:280 >> + LOG_ERROR("File failed to access. Error message: %s", safeStrerror(errno).data()); > > I think "file failed to access" is a vague message to put in a log, and not how I would describe a failure of the access function. If we are going to log this, then the message should make some mention of the fact that were were attempting to create directories, perhaps. Also wondering why we decided to log about the failure of this access call but not about the failures of the other access and mkdir calls below. > > Generally we want these file system abstraction functions like makeAllDirectories to not log directly to the console, so callers can make calls they know will or might fail without unconditionally cluttering logs. I understand that this conflicts with the desire to know what’s happening when diagnosing a bug. I’m not sure there is an easy answer. Generally speaking it would not be good if all file system calls logged what happened directly to the console, and certainly that’s not how the underlying POSIX functions behave.
I added the log here because I realized that !access() does not necessarily mean file does not exist; it could be something more serious (like the fullPath is null case). (I planned to add early return on errno != ENOENT, instead of error log, but I am not sure if that would exclude some valid cases...) I think it's fair that we don't want to indroduce unnecessary logs for file system calls. Since there's no known issue here so far, I will remove this line.
Sihui Liu
Comment 5
2022-03-04 16:46:42 PST
Created
attachment 453881
[details]
Patch
EWS
Comment 6
2022-03-04 22:03:23 PST
Committed
r290862
(
248093@main
): <
https://commits.webkit.org/248093@main
> All reviewed patches have been landed. Closing bug and clearing flags on
attachment 453881
[details]
.
Radar WebKit Bug Importer
Comment 7
2022-03-04 22:04:18 PST
<
rdar://problem/89848974
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug