dataease
dataease copied to clipboard
dataease
[Feature] v2 tab 组件在进行移动端布局时，支持将 tab 组件里的内容取出来单独布局
DataEase 版本: v2.9
请描述您的需求或者改进建议. v2 tab 组件在进行移动端布局时，支持将 tab 组件里的内容取出来单独布局
Yes, ps::ps_disk_partitions() will tell you the type of the file system, if that's all you need.
@gaborcsardi is there an existing helper to find the device that corresponds to a path? Or do you just find the longest mountpoint prefix that matches your path?
I don't know of a way from R. You need to call statfs(2) on Unix, IDK on Windows.
ps_fs_info() will now return file system information for one or more paths: https://github.com/r-lib/ps/pull/165
It finds the file system of the input files/directories automatically.
In Docker it is not very exciting:
> ps_fs_info(c("/pkg", "~"))
# A data frame: 2 × 26
path mount_point name type block_size transfer_block_size total_data_blocks free_blocks free_blocks_non_supe…¹
<chr> <chr> <chr> <chr> <dbl> <dbl> <dbl> <dbl> <dbl>
1 /pkg /pkg :/Users/g… fuse… 1048576 1048576 242837545 60001470 60001470
2 ~ / overlay over… 4096 4096 25656302 11311661 9996858
# ℹ abbreviated name: ¹free_blocks_non_superuser
# ℹ 17 more variables: total_nodes <dbl>, free_nodes <dbl>, id <list>, owner <dbl>, type_code <dbl>,
# mount_flags_code <dbl>, subtype_code <dbl>, MANDLOCK <lgl>, NOATIME <lgl>, NODEV <lgl>, NODIRATIME <lgl>,
# NOEXEC <lgl>, NOSUID <lgl>, RDONLY <lgl>, RELATIME <lgl>, SYNCHRONOUS <lgl>, NOSYMFOLLOW <lgl>
ps_fs_info() will now return file system information for one or more paths: https://github.com/r-lib/ps/pull/165 It finds the file system of the input files/directories automatically.
Awesome, thanks @gaborcsardi! This looks like exactly what I need.
In Docker it is not very exciting
Not sure I follow. Is it because OverlayFS doesn't really tell us what the actual underlying file system is?
I just added https://github.com/ropensci/targets/pull/1326 to (mostly) fix #1315. Still a few to-dos listed in the PR.
Just a heads up (and really more of a comment for @gaborcsardi), this leads to some issues if you're running a targets pipeline as a kubernetes cronjob. Has to do with ps_disk_partitions accessing /etc/mtab. A current workaround I found is to create a symbolic link between /proc/self/mounts and /etc/mtab, however I imagine there might be more graceful solutions.
It doesn't exist in the kubernetes environment. Was a real pain to figure that out because it exists locally and in the docker container it was built with.
In general you have to be prepared that these calls might fail. Of course this is true in general, but even more true for functions in ps. E.g. some barebone Linux systems don't even have a /proc file system. I guess I could add this to the docs.
Just a heads up (and really more of a comment for @gaborcsardi), this leads to some issues if you're running a targets pipeline as a kubernetes cronjob. Has to do with ps_disk_partitions accessing /etc/mtab. A current workaround I found is to create a symbolic link between /proc/self/mounts and /etc/mtab, however I imagine there might be more graceful solutions.
What happens exactly? Is there a specific function in ps that throws an error?
IDK for sure, but mtab only appears once in the ps source code, so I guess it is an error here:
https://github.com/r-lib/ps/blob/1e8305b0f5194d40f7bb854d2d5dde14dcca809b/src/api-linux.c#L1603
Thanks. In 06def2604e1646531f6da8e3af00b840c4d496f1, I have added error handling in targets around calls to ps::ps_disk_partitions() and ps::ps_fs_mount_point(). Hopefully that helps.
From what I was able to ascertain, I agree with @gaborcsardi. On the targets side, the issue arises after calling tar_make() as under the hood it's using runtime_file_systems to get the file information which calls ps::ps_disk_partitions(). I've attached the traceback error. Hopefully https://github.com/ropensci/targets/commit/06def2604e1646531f6da8e3af00b840c4d496f1 will help.
-- Last error traceback ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ tar_make(callr_function = NULL) callr_outer(targets_function = tar_make_inner, targets_arguments = targe... callr_dispatch(targets_function = targets_function, targets_arguments = ... if_any(is.null(callr_function), callr_inner(targets_function = targets_f... callr_inner(targets_function = targets_function, targets_arguments = tar... tryCatch(out <- withCallingHandlers(targets::tar_callr_inner_try(targets... tryCatchList(expr, classes, parentenv, handlers) tryCatchOne(expr, names, parentenv, handlers[[1L]]) doTryCatch(return(expr), name, parentenv, handler) withCallingHandlers(targets::tar_callr_inner_try(targets_function = targ... targets::tar_callr_inner_try(targets_function = targets_function, target... callr_set_runtime(script = script, store = store, fun = fun, pid_parent ... runtime_set_file_info(tar_runtime, store) trust_timestamps(store) runtime_file_systems() ps::ps_disk_partitions() not_null(.Call(ps__disk_partitions, all))