Menu
▾
▴
#24 Patch against bug 3329249
The issue surfaced when I attempted to use 7za to provide a VM backup solution on ESXi platform. If the VM is powered off I am able to zip the VM directory as well as all related files; but for powered ON VMs given the vmdk file is locked by hypervisor, the only solution is to first create a snapshot file and then zip up the unlocked VMDK file. Suprisigly 9.20 fails if compression option is mx=1, it fails with error E_FAIL. With no-compression operation selected the operation is a success.
The submitted patch replaces the system call for "file operation" to use C library file operation calls, that works fine. It is tested against VM of sizes as big as 100G and it works fine.
Thanks!
Ata
open/close/read/write/lseek are functions which are available in old and new Unix.
I don't know about fseeko/ftello/..
And what about : ftruncate(fileno(_fd), pos_cur) ?
Moreover:
! case CREATE_NEW : flags += "w"; break;
! case CREATE_ALWAYS : flags += "w"; break;
! case OPEN_EXISTING : break;
! case OPEN_ALWAYS : flags += "w"; break;
CREATE_NEW and CREATE_ALWAYS don't have the same behaviour
but for "fopen", you use "w" ...
What OS is ESXi platform ? Linux ?
I don't understand why "fopen" works and not open.
On Unix, fopen uses open ...
Perhaps, on your platform, you need to add a flag for "open".
What flags were used when the open failed ?
#ifdef O_MY_FLAG_FOR_THIS_PLATFORM
flags |= O_MY_FLAG_FOR_THIS_PLATFORM;
#endif
Where O_MY_FLAG_FOR_THIS_PLATFORM makes open behave like fopen ...
I need to confirm this as its a long time, but the issue only came up with powerred ON VMs (snapshot file was created so data file *-flat.vmdk was freezed). IIRC, it was the issue with reading the file contents than just opening the file.
As fread/fwrite are different from read/write system calls (I think they use bcopy() or similar call to read the data and also they are buffered in nature of there operation), thus using C system library works whereas basic system calls where failing.
ESXi 4.1 which I used is 32 bit OS close to Linux but not compeltly a Linux OS. In my test I opened the file in RD_ONLY mode for open and "rb" for fread/fwrite.
fseeko/ftello supports 64 bit offset handling and is better to handle large files. At first I used fseek/ftell version of calls, but it failed for VMs with disk size ~100G or so.
So far, I was not able to see any issues replacing system calls with C library calls, given C library calls are reliable and widely used. Please share if you forsee any concerns.
Thanks!
Ata