在Linux上拦截文件操作 [英] Intercepting file operations on Linux
问题描述
我正在一个云平台上渲染视觉效果和动画.我们接受场景描述的各种格式来渲染它们，并将图像输出返回给用户.处理后端是Linux.有时，我们会收到Windows上生成的场景描述，因此我们获得的路径类似于"C:\ path \ to \ file.mb".我已经编写了一个Linux共享库来拦截各种文件系统调用，并将路径更改为Linux可以理解的'/C/path/to/file'.我使用LD_PRELOAD机制将函数插入真实"函数之前，并且效果很好……除非不是.
I'm working on a cloud platform for rendering visual effects and animation. We accept various formats of scene descriptions render them, and return the image outputs to the user. The processing backend is Linux. Sometimes we receive scene descriptions generated on Windows so we get paths that look like 'C:\path\to\file.mb'. I've written a Linux shared library to intercept various filesystem calls and alter the paths to something Linux can understand '/C/path/to/file'. I use the LD_PRELOAD mechanism to insert my functions before the "real" ones and it works great... except when it doesn't.
例如以下命令:
LD_PRELOAD =/home/robert/path_fix.so渲染-s 1 -e 1 C:\ path \ to \ test_scene_03_vray.ma
LD_PRELOAD=/home/robert/path_fix.so Render -s 1 -e 1 C:\path\to\test_scene_03_vray.ma
将找不到test_scene_03_vray.ma.这也行不通:
Will not locate test_scene_03_vray.ma. This also doesn't work:
LD_PRELOAD =/home/robert/path_fix.so回声测试> C:\ path \ to \ test.txt
LD_PRELOAD=/home/robert/path_fix.so echo test > C:\path\to\test.txt
我一直在使用ltrace找出使用路径名引用调用的函数，但是这些示例未显示在跟踪中:
I've been using ltrace to figure out which functions are called with references to path names, but these examples don't show up in my traces:
ltrace -f -C -S -o ltrace.out渲染C:\ path \ to \ test_scene_03_vray.ma
ltrace -f -C -S -o ltrace.out Render C:\path\to\test_scene_03_vray.ma
除了ltrace之外，还有其他工具可以让我看到调用了哪些函数调用吗?
Is there a tool other than ltrace that will let me see which function calls are invoked?
以下是我已经覆盖的内容列表:
Here's the list of what I already have overrides for:
- 打开
- freopen
- opendir
- 打开
- 创建
- openat
- stat
- lstat
- fstatat
- __ lxstat
- __ xstat
- mkdir
- mkdirat
- 取消链接
- unlinkat
- 访问
- faccessat
- 重命名
- 重命名
- renameat2
- chmod
- fchmodat
- 小丑
- lchown
- fchownat
- 链接
- linkat
- name_to_handle_at
- readlink
- readlinkat
- 符号链接
- 符号链接
- rmdir
- chdir
- fopen
- freopen
- opendir
- open
- creat
- openat
- stat
- lstat
- fstatat
- __lxstat
- __xstat
- mkdir
- mkdirat
- unlink
- unlinkat
- access
- faccessat
- rename
- renameat
- renameat2
- chmod
- fchmodat
- chown
- lchown
- fchownat
- link
- linkat
- name_to_handle_at
- readlink
- readlinkat
- symlink
- symlinkat
- rmdir
- chdir
我在这里还缺少更多功能吗?我试图实现所有需要
Are there more functions that I'm missing here? I tried to implement everything that takes
const char *文件路径
const char *filepath
作为参数.
侧面问题:看来这可能已经是一个解决的问题...是否存在将Windows路径转换为unix友好路径的库或其他方法?请记住，渲染应用程序是第三方专有二进制文件，因此我无法对其进行修改.
Side question: This seems like it might already be a solved problem... Is there a library or other approach that converts Windows paths to unix friendly paths? Keep in mind that the rendering applications are 3rd party proprietary binaries so I can't modify them.
谢谢您的建议！
推荐答案
是的，还有其他功能，例如64位功能open64().还有__open()之类的功能.
Yes, there are other functions, such as the 64-bit functions open64(). There are also functions such as __open().
在64位Centos 7服务器上，仅open我得到:
On a 64-bit Centos 7 server, for just open I get:
nm -D /lib64/libc.so.6 | grep open
0000000000033d70 T catopen
00000000003c0b80 B _dl_open_hook
000000000006b140 T fdopen
00000000000ba4c0 W fdopendir
00000000000755d0 T fmemopen
000000000006ba00 T fopen
000000000006ba00 W fopen64
000000000006bb60 T fopencookie
0000000000073700 T freopen
0000000000074b60 T freopen64
00000000000eb7a0 T fts_open
0000000000022220 T iconv_open
000000000006b140 T _IO_fdopen
0000000000077230 T _IO_file_fopen
0000000000077180 T _IO_file_open
000000000006ba00 T _IO_fopen
000000000006d1d0 T _IO_popen
000000000006cee0 T _IO_proc_open
0000000000131580 T __libc_dlopen_mode
00000000000e82a0 W open
00000000000e82a0 W __open
00000000000ed0f0 T __open_2
00000000000e82a0 W open64
00000000000e82a0 W __open64
00000000000ed110 T __open64_2
00000000000e8330 W openat
00000000000e8410 T __openat_2
00000000000e8330 W openat64
00000000000e8410 W __openat64_2
00000000000f7860 T open_by_handle_at
00000000000340b0 T __open_catalog
00000000000b9f70 W opendir
00000000000f12b0 T openlog
0000000000073ea0 T open_memstream
00000000000731c0 T open_wmemstream
000000000006d1d0 T popen
0000000000130630 W posix_openpt
00000000000e6ec0 T posix_spawn_file_actions_addopen
例如，在Linux上，此C代码很可能正常工作:
For example, on Linux this C code is quite likely to work just fine:
int fd = __open( path, O_RDONLY );
您也不会捕获静态链接的进程，也不会捕获直接发出系统调用的进程，例如open.
You're also not going to catch statically-linked processes, or those that issue a system call such as open directly.
这篇关于在Linux上拦截文件操作的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
