Rsync Error 23: Can I tell which files were not transferred?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
27
down vote

favorite
4












I ran sudo rsync -va --progress from the root of one external drive to a folder on another external drive. The reason is that the source drive has an error-ful NTFS and I don't have access to a Windows PC to repair the NTFS.



10 hours later it said:



sent 608725204596 bytes received 19365712 bytes 15902210.53 bytes/sec
total size is 608586212274 speedup is 1.00
rsync error: some files could not be transferred (code 23) at /SourceCache/rsync/rsync-42/rsync/main.c(992) [sender=2.6.9]


I saved the entire terminal output. At the beginning, there are a few hundred Input/output error (5) for files I actually don't need totaling roughly 2GB. OSX Finder "disk usage" tells me the source is 617 billion bytes, not 608 as in the above report.



Questions:



  1. Does the first portion of the verbose output (building a file list) definitely say Input/output error (5) for EVERY file that won't be copied?

  2. Does code 23 mean that all the files except the Input/output error (5) ones were successfully copied?









share|improve this question























  • Possibly helpful: rsync error messages appear to start with "rsync: ", so grep '^rsync: ' output may be helpful.
    – barrycarter
    Sep 25 '17 at 13:47














up vote
27
down vote

favorite
4












I ran sudo rsync -va --progress from the root of one external drive to a folder on another external drive. The reason is that the source drive has an error-ful NTFS and I don't have access to a Windows PC to repair the NTFS.



10 hours later it said:



sent 608725204596 bytes received 19365712 bytes 15902210.53 bytes/sec
total size is 608586212274 speedup is 1.00
rsync error: some files could not be transferred (code 23) at /SourceCache/rsync/rsync-42/rsync/main.c(992) [sender=2.6.9]


I saved the entire terminal output. At the beginning, there are a few hundred Input/output error (5) for files I actually don't need totaling roughly 2GB. OSX Finder "disk usage" tells me the source is 617 billion bytes, not 608 as in the above report.



Questions:



  1. Does the first portion of the verbose output (building a file list) definitely say Input/output error (5) for EVERY file that won't be copied?

  2. Does code 23 mean that all the files except the Input/output error (5) ones were successfully copied?









share|improve this question























  • Possibly helpful: rsync error messages appear to start with "rsync: ", so grep '^rsync: ' output may be helpful.
    – barrycarter
    Sep 25 '17 at 13:47












up vote
27
down vote

favorite
4









up vote
27
down vote

favorite
4






4





I ran sudo rsync -va --progress from the root of one external drive to a folder on another external drive. The reason is that the source drive has an error-ful NTFS and I don't have access to a Windows PC to repair the NTFS.



10 hours later it said:



sent 608725204596 bytes received 19365712 bytes 15902210.53 bytes/sec
total size is 608586212274 speedup is 1.00
rsync error: some files could not be transferred (code 23) at /SourceCache/rsync/rsync-42/rsync/main.c(992) [sender=2.6.9]


I saved the entire terminal output. At the beginning, there are a few hundred Input/output error (5) for files I actually don't need totaling roughly 2GB. OSX Finder "disk usage" tells me the source is 617 billion bytes, not 608 as in the above report.



Questions:



  1. Does the first portion of the verbose output (building a file list) definitely say Input/output error (5) for EVERY file that won't be copied?

  2. Does code 23 mean that all the files except the Input/output error (5) ones were successfully copied?









share|improve this question















I ran sudo rsync -va --progress from the root of one external drive to a folder on another external drive. The reason is that the source drive has an error-ful NTFS and I don't have access to a Windows PC to repair the NTFS.



10 hours later it said:



sent 608725204596 bytes received 19365712 bytes 15902210.53 bytes/sec
total size is 608586212274 speedup is 1.00
rsync error: some files could not be transferred (code 23) at /SourceCache/rsync/rsync-42/rsync/main.c(992) [sender=2.6.9]


I saved the entire terminal output. At the beginning, there are a few hundred Input/output error (5) for files I actually don't need totaling roughly 2GB. OSX Finder "disk usage" tells me the source is 617 billion bytes, not 608 as in the above report.



Questions:



  1. Does the first portion of the verbose output (building a file list) definitely say Input/output error (5) for EVERY file that won't be copied?

  2. Does code 23 mean that all the files except the Input/output error (5) ones were successfully copied?






rsync






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Aug 26 at 14:41









Jeff Schaller

32.7k849110




32.7k849110










asked Feb 14 '14 at 0:37









themirror

2,278102030




2,278102030











  • Possibly helpful: rsync error messages appear to start with "rsync: ", so grep '^rsync: ' output may be helpful.
    – barrycarter
    Sep 25 '17 at 13:47
















  • Possibly helpful: rsync error messages appear to start with "rsync: ", so grep '^rsync: ' output may be helpful.
    – barrycarter
    Sep 25 '17 at 13:47















Possibly helpful: rsync error messages appear to start with "rsync: ", so grep '^rsync: ' output may be helpful.
– barrycarter
Sep 25 '17 at 13:47




Possibly helpful: rsync error messages appear to start with "rsync: ", so grep '^rsync: ' output may be helpful.
– barrycarter
Sep 25 '17 at 13:47










3 Answers
3






active

oldest

votes

















up vote
12
down vote













23 only means (from the man page):




23 Partial transfer due to error




For everything that could not be transferred, you'll get an error message. Note that the error messages could be about opening or reading directories, so you won't necessarily see an error message for each file that could not be transferred.



If your source has not changed, you can run the rsync again with -n to see what it would transfer this time without actually doing the transfer.



About the byte difference, rsync gives you the size of the files (how much data can be read from them). Are you sure Finder doesn't tell you the disk usage instead?



Also note that NTFS can store data in alternate streams or attributes of the files, and rsync will typically not transfer (is not aware of) those (and that can account for a lot as well).






share|improve this answer






















  • So are you saying that ALL of the data (no matter how corrupted) that was not transferred was listed at the beginning as a Input/output error (5)?
    – themirror
    Feb 14 '14 at 15:46










  • regarding byte difference: Yes that is correct. I'm confused though about why the difference between rsync's report and Finder's "disk usage" is 9 billion bytes but I can only identify 2-3 billion bytes of files that said Input/output error (5). Can you explain?
    – themirror
    Feb 14 '14 at 15:48






  • 1




    @themirror, a 1-byte file will still need a few kilo-bytes allocated on disk to store it (try echo > file; du -k file to see how much on the source filesystem, but on ntfs, it's usually 4k). rsync will tell you that the size is 1, but Finder might tell you 4096 for that file.
    – Stéphane Chazelas
    Feb 14 '14 at 15:56










  • @themirror, wrt your first comment, I'm saying that for everything (file content, see my edit about alternate streams) that could not be transferred, you'll get an error, but if you get a can't read directory /foo, then obviously /foo/bar and /foo/bar/baz won't have been transferred either.
    – Stéphane Chazelas
    Feb 14 '14 at 16:01

















up vote
9
down vote













You can silence rsync's non-error output using rsync's -q flag.



-q, --quiet suppress non-error messages


If you run rsync again with the -q flag, rsync will likely still fail, but at least this time any error messages that are causing your problem will not be buried under lines and lines of file transfer status messages.






share|improve this answer



























    up vote
    1
    down vote













    Re: error 23-- The most common reason to have this error is to make a minor typo entering in the rsync source. Look over your source command and make sure everything checks out against ls, and look for stupid subtle things like an extra space or a 1-l problem.






    share|improve this answer




















    • I know it is silly, but I even went the route to keep digging through the code until I realized I had made this dumb mistake. Thank you!
      – rburhum
      Nov 13 '17 at 18:06










    Your Answer







    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "106"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: false,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );













     

    draft saved


    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f115116%2frsync-error-23-can-i-tell-which-files-were-not-transferred%23new-answer', 'question_page');

    );

    Post as a guest






























    3 Answers
    3






    active

    oldest

    votes








    3 Answers
    3






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    12
    down vote













    23 only means (from the man page):




    23 Partial transfer due to error




    For everything that could not be transferred, you'll get an error message. Note that the error messages could be about opening or reading directories, so you won't necessarily see an error message for each file that could not be transferred.



    If your source has not changed, you can run the rsync again with -n to see what it would transfer this time without actually doing the transfer.



    About the byte difference, rsync gives you the size of the files (how much data can be read from them). Are you sure Finder doesn't tell you the disk usage instead?



    Also note that NTFS can store data in alternate streams or attributes of the files, and rsync will typically not transfer (is not aware of) those (and that can account for a lot as well).






    share|improve this answer






















    • So are you saying that ALL of the data (no matter how corrupted) that was not transferred was listed at the beginning as a Input/output error (5)?
      – themirror
      Feb 14 '14 at 15:46










    • regarding byte difference: Yes that is correct. I'm confused though about why the difference between rsync's report and Finder's "disk usage" is 9 billion bytes but I can only identify 2-3 billion bytes of files that said Input/output error (5). Can you explain?
      – themirror
      Feb 14 '14 at 15:48






    • 1




      @themirror, a 1-byte file will still need a few kilo-bytes allocated on disk to store it (try echo > file; du -k file to see how much on the source filesystem, but on ntfs, it's usually 4k). rsync will tell you that the size is 1, but Finder might tell you 4096 for that file.
      – Stéphane Chazelas
      Feb 14 '14 at 15:56










    • @themirror, wrt your first comment, I'm saying that for everything (file content, see my edit about alternate streams) that could not be transferred, you'll get an error, but if you get a can't read directory /foo, then obviously /foo/bar and /foo/bar/baz won't have been transferred either.
      – Stéphane Chazelas
      Feb 14 '14 at 16:01














    up vote
    12
    down vote













    23 only means (from the man page):




    23 Partial transfer due to error




    For everything that could not be transferred, you'll get an error message. Note that the error messages could be about opening or reading directories, so you won't necessarily see an error message for each file that could not be transferred.



    If your source has not changed, you can run the rsync again with -n to see what it would transfer this time without actually doing the transfer.



    About the byte difference, rsync gives you the size of the files (how much data can be read from them). Are you sure Finder doesn't tell you the disk usage instead?



    Also note that NTFS can store data in alternate streams or attributes of the files, and rsync will typically not transfer (is not aware of) those (and that can account for a lot as well).






    share|improve this answer






















    • So are you saying that ALL of the data (no matter how corrupted) that was not transferred was listed at the beginning as a Input/output error (5)?
      – themirror
      Feb 14 '14 at 15:46










    • regarding byte difference: Yes that is correct. I'm confused though about why the difference between rsync's report and Finder's "disk usage" is 9 billion bytes but I can only identify 2-3 billion bytes of files that said Input/output error (5). Can you explain?
      – themirror
      Feb 14 '14 at 15:48






    • 1




      @themirror, a 1-byte file will still need a few kilo-bytes allocated on disk to store it (try echo > file; du -k file to see how much on the source filesystem, but on ntfs, it's usually 4k). rsync will tell you that the size is 1, but Finder might tell you 4096 for that file.
      – Stéphane Chazelas
      Feb 14 '14 at 15:56










    • @themirror, wrt your first comment, I'm saying that for everything (file content, see my edit about alternate streams) that could not be transferred, you'll get an error, but if you get a can't read directory /foo, then obviously /foo/bar and /foo/bar/baz won't have been transferred either.
      – Stéphane Chazelas
      Feb 14 '14 at 16:01












    up vote
    12
    down vote










    up vote
    12
    down vote









    23 only means (from the man page):




    23 Partial transfer due to error




    For everything that could not be transferred, you'll get an error message. Note that the error messages could be about opening or reading directories, so you won't necessarily see an error message for each file that could not be transferred.



    If your source has not changed, you can run the rsync again with -n to see what it would transfer this time without actually doing the transfer.



    About the byte difference, rsync gives you the size of the files (how much data can be read from them). Are you sure Finder doesn't tell you the disk usage instead?



    Also note that NTFS can store data in alternate streams or attributes of the files, and rsync will typically not transfer (is not aware of) those (and that can account for a lot as well).






    share|improve this answer














    23 only means (from the man page):




    23 Partial transfer due to error




    For everything that could not be transferred, you'll get an error message. Note that the error messages could be about opening or reading directories, so you won't necessarily see an error message for each file that could not be transferred.



    If your source has not changed, you can run the rsync again with -n to see what it would transfer this time without actually doing the transfer.



    About the byte difference, rsync gives you the size of the files (how much data can be read from them). Are you sure Finder doesn't tell you the disk usage instead?



    Also note that NTFS can store data in alternate streams or attributes of the files, and rsync will typically not transfer (is not aware of) those (and that can account for a lot as well).







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Feb 14 '14 at 15:59

























    answered Feb 14 '14 at 6:30









    Stéphane Chazelas

    285k53525864




    285k53525864











    • So are you saying that ALL of the data (no matter how corrupted) that was not transferred was listed at the beginning as a Input/output error (5)?
      – themirror
      Feb 14 '14 at 15:46










    • regarding byte difference: Yes that is correct. I'm confused though about why the difference between rsync's report and Finder's "disk usage" is 9 billion bytes but I can only identify 2-3 billion bytes of files that said Input/output error (5). Can you explain?
      – themirror
      Feb 14 '14 at 15:48






    • 1




      @themirror, a 1-byte file will still need a few kilo-bytes allocated on disk to store it (try echo > file; du -k file to see how much on the source filesystem, but on ntfs, it's usually 4k). rsync will tell you that the size is 1, but Finder might tell you 4096 for that file.
      – Stéphane Chazelas
      Feb 14 '14 at 15:56










    • @themirror, wrt your first comment, I'm saying that for everything (file content, see my edit about alternate streams) that could not be transferred, you'll get an error, but if you get a can't read directory /foo, then obviously /foo/bar and /foo/bar/baz won't have been transferred either.
      – Stéphane Chazelas
      Feb 14 '14 at 16:01
















    • So are you saying that ALL of the data (no matter how corrupted) that was not transferred was listed at the beginning as a Input/output error (5)?
      – themirror
      Feb 14 '14 at 15:46










    • regarding byte difference: Yes that is correct. I'm confused though about why the difference between rsync's report and Finder's "disk usage" is 9 billion bytes but I can only identify 2-3 billion bytes of files that said Input/output error (5). Can you explain?
      – themirror
      Feb 14 '14 at 15:48






    • 1




      @themirror, a 1-byte file will still need a few kilo-bytes allocated on disk to store it (try echo > file; du -k file to see how much on the source filesystem, but on ntfs, it's usually 4k). rsync will tell you that the size is 1, but Finder might tell you 4096 for that file.
      – Stéphane Chazelas
      Feb 14 '14 at 15:56










    • @themirror, wrt your first comment, I'm saying that for everything (file content, see my edit about alternate streams) that could not be transferred, you'll get an error, but if you get a can't read directory /foo, then obviously /foo/bar and /foo/bar/baz won't have been transferred either.
      – Stéphane Chazelas
      Feb 14 '14 at 16:01















    So are you saying that ALL of the data (no matter how corrupted) that was not transferred was listed at the beginning as a Input/output error (5)?
    – themirror
    Feb 14 '14 at 15:46




    So are you saying that ALL of the data (no matter how corrupted) that was not transferred was listed at the beginning as a Input/output error (5)?
    – themirror
    Feb 14 '14 at 15:46












    regarding byte difference: Yes that is correct. I'm confused though about why the difference between rsync's report and Finder's "disk usage" is 9 billion bytes but I can only identify 2-3 billion bytes of files that said Input/output error (5). Can you explain?
    – themirror
    Feb 14 '14 at 15:48




    regarding byte difference: Yes that is correct. I'm confused though about why the difference between rsync's report and Finder's "disk usage" is 9 billion bytes but I can only identify 2-3 billion bytes of files that said Input/output error (5). Can you explain?
    – themirror
    Feb 14 '14 at 15:48




    1




    1




    @themirror, a 1-byte file will still need a few kilo-bytes allocated on disk to store it (try echo > file; du -k file to see how much on the source filesystem, but on ntfs, it's usually 4k). rsync will tell you that the size is 1, but Finder might tell you 4096 for that file.
    – Stéphane Chazelas
    Feb 14 '14 at 15:56




    @themirror, a 1-byte file will still need a few kilo-bytes allocated on disk to store it (try echo > file; du -k file to see how much on the source filesystem, but on ntfs, it's usually 4k). rsync will tell you that the size is 1, but Finder might tell you 4096 for that file.
    – Stéphane Chazelas
    Feb 14 '14 at 15:56












    @themirror, wrt your first comment, I'm saying that for everything (file content, see my edit about alternate streams) that could not be transferred, you'll get an error, but if you get a can't read directory /foo, then obviously /foo/bar and /foo/bar/baz won't have been transferred either.
    – Stéphane Chazelas
    Feb 14 '14 at 16:01




    @themirror, wrt your first comment, I'm saying that for everything (file content, see my edit about alternate streams) that could not be transferred, you'll get an error, but if you get a can't read directory /foo, then obviously /foo/bar and /foo/bar/baz won't have been transferred either.
    – Stéphane Chazelas
    Feb 14 '14 at 16:01












    up vote
    9
    down vote













    You can silence rsync's non-error output using rsync's -q flag.



    -q, --quiet suppress non-error messages


    If you run rsync again with the -q flag, rsync will likely still fail, but at least this time any error messages that are causing your problem will not be buried under lines and lines of file transfer status messages.






    share|improve this answer
























      up vote
      9
      down vote













      You can silence rsync's non-error output using rsync's -q flag.



      -q, --quiet suppress non-error messages


      If you run rsync again with the -q flag, rsync will likely still fail, but at least this time any error messages that are causing your problem will not be buried under lines and lines of file transfer status messages.






      share|improve this answer






















        up vote
        9
        down vote










        up vote
        9
        down vote









        You can silence rsync's non-error output using rsync's -q flag.



        -q, --quiet suppress non-error messages


        If you run rsync again with the -q flag, rsync will likely still fail, but at least this time any error messages that are causing your problem will not be buried under lines and lines of file transfer status messages.






        share|improve this answer












        You can silence rsync's non-error output using rsync's -q flag.



        -q, --quiet suppress non-error messages


        If you run rsync again with the -q flag, rsync will likely still fail, but at least this time any error messages that are causing your problem will not be buried under lines and lines of file transfer status messages.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Oct 13 '15 at 11:43









        Grimtech

        19113




        19113




















            up vote
            1
            down vote













            Re: error 23-- The most common reason to have this error is to make a minor typo entering in the rsync source. Look over your source command and make sure everything checks out against ls, and look for stupid subtle things like an extra space or a 1-l problem.






            share|improve this answer




















            • I know it is silly, but I even went the route to keep digging through the code until I realized I had made this dumb mistake. Thank you!
              – rburhum
              Nov 13 '17 at 18:06














            up vote
            1
            down vote













            Re: error 23-- The most common reason to have this error is to make a minor typo entering in the rsync source. Look over your source command and make sure everything checks out against ls, and look for stupid subtle things like an extra space or a 1-l problem.






            share|improve this answer




















            • I know it is silly, but I even went the route to keep digging through the code until I realized I had made this dumb mistake. Thank you!
              – rburhum
              Nov 13 '17 at 18:06












            up vote
            1
            down vote










            up vote
            1
            down vote









            Re: error 23-- The most common reason to have this error is to make a minor typo entering in the rsync source. Look over your source command and make sure everything checks out against ls, and look for stupid subtle things like an extra space or a 1-l problem.






            share|improve this answer












            Re: error 23-- The most common reason to have this error is to make a minor typo entering in the rsync source. Look over your source command and make sure everything checks out against ls, and look for stupid subtle things like an extra space or a 1-l problem.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Jan 11 '17 at 4:39









            blut swaan

            111




            111











            • I know it is silly, but I even went the route to keep digging through the code until I realized I had made this dumb mistake. Thank you!
              – rburhum
              Nov 13 '17 at 18:06
















            • I know it is silly, but I even went the route to keep digging through the code until I realized I had made this dumb mistake. Thank you!
              – rburhum
              Nov 13 '17 at 18:06















            I know it is silly, but I even went the route to keep digging through the code until I realized I had made this dumb mistake. Thank you!
            – rburhum
            Nov 13 '17 at 18:06




            I know it is silly, but I even went the route to keep digging through the code until I realized I had made this dumb mistake. Thank you!
            – rburhum
            Nov 13 '17 at 18:06

















             

            draft saved


            draft discarded















































             


            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f115116%2frsync-error-23-can-i-tell-which-files-were-not-transferred%23new-answer', 'question_page');

            );

            Post as a guest













































































            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Displaying single band from multi-band raster using QGIS

            How many registers does an x86_64 CPU actually have?