https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=645
Leon <Echo77echo@xxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |Echo77echo@xxxxxxxxx
--- Comment #4 from Leon <Echo77echo@xxxxxxxxx> 2012-02-16 06:58:24 PST ---
(In reply to comment #0)
> Build information:
> Paste the COMPLETE build information from "Help->About Ethereal" or "-v" output.
> --
>
> We do "safe save" when writing some user configuration files - we write the new contents out to a new
> file, check whether the close succeeds (to determine whether, for example, a delayed write to a file
> server failed; if such a delayed write fails, e.g. because the file system filled up or the user's quota was
> exceeded, a write() call won't return an error, and a WriteFile() call might not do so either), and, if the
> close succeeds, rename the new file on top of the old one.
>
> Unfortunately, it's not clear whether an fclose() on Windows will fail if there's such a delayed write error
> - CloseHandle() does *NOT* force data to be written out to stable storage, according to the Platform
> SDK - and it's not necessarily the case that it'll fail on UN*X (some UN*Xes do a sync-on-close for
> remote file systems, but I'm not sure all of them do).
>
> This might require that we do an fflush(), followed by an fsync() on UN*X and a FlushFileBuffers
> (HANDLE)_get_osfhandle(fd)) on Windows, and check whether both of *those* succeed.
>
> That forces a push to disk even on local file systems, but for user configuration files, at least, that's
> probably not a huge problem.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.
