Bug 1206663
| Summary: | Can't Drag'n'Drop file 2.4GB client->guest | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Andrei Stepanov <astepano> | |
| Component: | spice-vdagent | Assignee: | Default Assignee for SPICE Bugs <rh-spice-bugs> | |
| Status: | CLOSED ERRATA | QA Contact: | SPICE QE bug list <spice-qe-bugs> | |
| Severity: | unspecified | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 6.6 | CC: | ashankar, astepano, cfergeau, dblechte, fidencio, marcandre.lureau, mnewsome, pfrankli, rbalakri, spoyarek, tpelka | |
| Target Milestone: | rc | |||
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | spice-vdagent-0.14.0-7.el6 | Doc Type: | Bug Fix | |
| Doc Text: |
No doc needed
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 1331490 (view as bug list) | Environment: | ||
| Last Closed: | 2015-07-22 07:28:11 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1331490 | |||
|
Description
Andrei Stepanov
2015-03-27 16:39:25 UTC
Is not reproducible on x86_64 (In reply to Andrei Stepanov from comment #0) > 1. Create big file on client: dd if=/dev/zero of=bigone bs=1M count=2500 > 2. Try to drag-and-drop it to guest > > Actual results: > Mar 27 17:29:35.526930 spice-vdagent[2646]: err: file-xfer: err reserving > 2621440020 bytes for /home/astepano/Desktop/sbig: Invalid argument ... > I can create file on guest with required size. It is not a free space > problem. if (ftruncate(task->file_fd, task->file_size) < 0) { syslog(LOG_ERR, "file-xfer: err reserving %"PRIu64" bytes for %s: %s", task->file_size, path, strerror(errno)); goto error; } I guess we need ftruncte64 for this. According to truncate(2):
"Linux 2.4 added truncate64() and ftruncate64() system calls that handle large files. However, these details can be ignored by applications using glibc, whose wrapper functions transparently employ the more recent system calls where they are available."
"A header file bug in glibc 2.12 meant that the minimum value of _POSIX_C_SOURCE required to expose the declaration of ftruncate() was 200809L instead of 200112L. This has been fixed in later glibc versions."
I don't have 686 guest to test with, could you gcc/run this:
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <assert.h>
int main()
{
int fd = open("foo", O_CREAT | O_WRONLY, 0644);
assert (ftruncate(fd, 2621440020) == 0);
}
It shouldn't assert if you have enough disk space, I think. If it does, it might be a glibc backport missing, or we need to recompile the agent perhaps..
moving to glibc maintainers for help. Shouldn't the program in comment 4 work on i686, or it should be using ftruncate64 there? (In reply to Marc-Andre Lureau from comment #6) > moving to glibc maintainers for help. > > Shouldn't the program in comment 4 work on i686, or it should be using > ftruncate64 there? I can reproduce the failed assert when building on i686 with gcc ftruncate.c However, gcc -D_FILE_OFFSET_BITS=64 ftruncate.c does not assert. Checked with nm that in the former case, ftruncate@@GLIBC_2.0 is used, in the latter case, ftruncate64@@GLIBC_2.1 is used. Similar situation when building spice-vdagent, without AC_SYS_LARGEFILE in configure.ac, ftruncate is used, with AC_SYS_LARGEFILE, ftruncate64 is used. Clearing needinfo since comment 8 resolves this; -D_FILE_OFFSET_BITS=64 is needed to transparently substitute ftruncate with ftruncate64. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2015-1392.html |