You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
File watches are a feature that would make checking for data consistency a lot easier on users. Therefore, CrashMonkey should support a system where a user can tell CrashMonkey what files should no longer change. These watches may be tied to certain checkpoints in the workload, or they may be something that holds through the entire workload.
For watches, we can assume a few things:
the call will block until the watch has been setup
the watch will either reference a checkpoint, or be before any file system operations have completed
if the watch references a checkpoint, the watch function is called directly after a call to checkpoint
This part of the watch infrastructure implements the logic for file watches. For each file watch made, the CrashMonkey test harness should checksum the data and selective metadata for the specified file. Metadata that does not change on every access (ex. file size, file type, and permissions but not things like accessed time) should be included in the checksum. Checksums should be stored in a hashmap (or hashmap like structure) that maps the file name to the checksum.
There is no limit on the number of times a file can be added to watches. Therefore, each filepath<->checksum hashmap should be stored according to the checkpoint that it corresponds to (ex. if a file is watched referencing checkpoint 1 and checkpoint 2 -- as two separate calls to watch -- then there should be a hashmap corresponding to checkpoint 1 watches and a hashmap corresponding to checkpoint 2 watches).
The text was updated successfully, but these errors were encountered:
File watches are a feature that would make checking for data consistency a lot easier on users. Therefore, CrashMonkey should support a system where a user can tell CrashMonkey what files should no longer change. These watches may be tied to certain checkpoints in the workload, or they may be something that holds through the entire workload.
For watches, we can assume a few things:
This part of the watch infrastructure implements the logic for file watches. For each file watch made, the CrashMonkey test harness should checksum the data and selective metadata for the specified file. Metadata that does not change on every access (ex. file size, file type, and permissions but not things like accessed time) should be included in the checksum. Checksums should be stored in a hashmap (or hashmap like structure) that maps the file name to the checksum.
There is no limit on the number of times a file can be added to watches. Therefore, each filepath<->checksum hashmap should be stored according to the checkpoint that it corresponds to (ex. if a file is watched referencing checkpoint 1 and checkpoint 2 -- as two separate calls to watch -- then there should be a hashmap corresponding to checkpoint 1 watches and a hashmap corresponding to checkpoint 2 watches).
The text was updated successfully, but these errors were encountered: