#582 ntfs to ufs copy problem for large files

v0.69x
open
Volker
5
2014-04-02
2009-06-11
ugur yemez
No

Files larger than around 4.2GB cannot copy from NTFS to UFS.
The problem can be duplicated with cp or rsync command.

2.346.899.456 bytes ok
2.348.886.911 bytes ok
2.742.135.098 bytes ok
4.182.354.632 bytes ok
4.299.663.185 bytes nok
4.679.679.008 bytes nok

"rsync error: some files/attrs were not transferred (see preveious errors) (code 23) at main.c(1040) [sender=3.0.5]" error is given and the file transfer is not completed.
My command line parameter: rsync source file /destination folder/

Discussion

  • Volker

    Volker - 2009-06-12

    Some test results:

    Copying a 5.7 GiB file from NTFS to UFS, using 'truss' to trace the 'cp' command.

    write(4,"nterfaces:"\nmsgstr " interfaces"...,65536) = 65536 (0x10000)
    read(3,"/a> settings."\nmsgstr ""\n"Assu"...,65536) = 65536 (0x10000)
    write(4,"/a> settings."\nmsgstr ""\n"Assu"...,65536) = 65536 (0x10000)
    read(3,0x804c780,65536) = 0 (0x0)
    close(3) = 0 (0x0)
    close(4) = 0 (0x0)
    close(3) ERR#9 'Bad file descriptor'
    sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGU RG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTAL RM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0)
    sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
    sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGU RG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTAL RM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0)
    sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
    process exit, rval = 0

    The copy process stops at 1.7GiB of 5.7GiB.

     
  • Volker

    Volker - 2009-06-12

    OK,
    did some more research and tests. I was able to copy a 5.x GiB file successfully in 6 tries :-(

    Every time i got the same error result:
    read(3,0x804c780,65536) = 0 (0x0)
    close(3) = 0 (0x0)
    ...
    close(3) ERR#9 'Bad file descriptor'

    So, filehandle 3 is the origin file to be copied which is located on the NTFS filesystem. So i assume something with ntfs-3g goes wrong which will cause damage the filehandle in some way.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks