Renamed omdir -> handle
- lfs3_omdir_t -> lfs3_handle_t - lfs3.omdirs -> lfs3.handles - o -> h - lfs3_omdir_* -> lfs3_handle_* - lfs3_omdir_ismidopen -> lfs3_mid_isopen From conversations with users, the term "handle" or "file handle" seems to be the most common/easily understood term for the lfs3_file_t struct itself. It makes sense to adopt this in our codebase. I usually dislike inventing new names for things when prefixes can imply a relationship (size -> ssize, cache -> rcache, shrub -> bshrub, etc), but lfs3_omdirs_t was probably a bit much.
This commit is contained in:
@@ -5006,7 +5006,7 @@ code = '''
|
||||
|
||||
pos = pos - (weight/2) + 1;
|
||||
}
|
||||
file.b.o.flags |= LFS3_o_UNSYNC;
|
||||
file.b.h.flags |= LFS3_o_UNSYNC;
|
||||
lfs3_file_close(&lfs3, &file) => 0;
|
||||
|
||||
for (int remount = 0; remount < 2; remount++) {
|
||||
@@ -5116,7 +5116,7 @@ code = '''
|
||||
|
||||
pos = pos - (weight/2) + 1;
|
||||
}
|
||||
file.b.o.flags |= LFS3_o_UNSYNC;
|
||||
file.b.h.flags |= LFS3_o_UNSYNC;
|
||||
lfs3_file_close(&lfs3, &file) => 0;
|
||||
|
||||
for (int remount = 0; remount < 2; remount++) {
|
||||
|
||||
Reference in New Issue
Block a user