Welcome guest. Before posting on our computer help forum, you must register. Click here it's easy and free.

Author Topic: xcopy problem from one mem card > PC > new mem card  (Read 9138 times)

0 Members and 1 Guest are viewing this topic.

BC_Programmer


    Mastermind
  • Typing is no substitute for thinking.
  • Thanked: 1140
    • Yes
    • Yes
    • BC-Programming.com
  • Certifications: List
  • Computer: Specs
  • Experience: Beginner
  • OS: Windows 11
Re: xcopy problem from one mem card > PC > new mem card
« Reply #15 on: July 26, 2015, 11:48:07 PM »
The issue is that files have attributes and some are system and hidden files. 
xcopy will not copy them if you don't use the right switches.

This is true. However, their original command includes the appropriate /H switch. The 'fixed' version does not.

I can think of no difference between /S /E /V (The "working" version) and /S /I /E /H /Y /O that would cause the former to work, and the latter to not. The only difference is the target specification.
I was trying to dereference Null Pointers before it was cool.

foxidrive



    Specialist
  • Thanked: 268
  • Experience: Experienced
  • OS: Windows 8
Re: xcopy problem from one mem card > PC > new mem card
« Reply #16 on: July 27, 2015, 08:47:48 AM »

foxidrive



    Specialist
  • Thanked: 268
  • Experience: Experienced
  • OS: Windows 8
Re: xcopy problem from one mem card > PC > new mem card
« Reply #17 on: July 27, 2015, 08:54:06 AM »
This is true. However, their original command includes the appropriate /H switch. The 'fixed' version does not.

I can think of no difference between /S /E /V (The "working" version) and /S /I /E /H /Y /O that would cause the former to work, and the latter to not. The only difference is the target specification.

You're absolutely right.  In fact the "working" one has /S and /V which have absolutely no effect on what is copied at all, and it doesn't copy hidden or system files.

I suspect he was never for a solution...

It's looking very much that way.

NorrinRadd

    Topic Starter


    Greenhorn

    • Experience: Experienced
    • OS: Windows Vista
    Re: xcopy problem from one mem card > PC > new mem card
    « Reply #18 on: July 28, 2015, 12:06:18 PM »
    Well if you're going to come after me like that twice now foxidrive then I'll respond.

    The "thankfully" was earned by the poster on the toms forum, not you; your "It's looking very much that way" is your own snarky reaction to a legitimate question posted to this forum and the workable answer having come from a different forum.

    You seem to take this personally, you shouldn't.

    I didn't care who answered it, just needed the fix, got it, reported that back responsibly.

    Posters like BC_Programmer add value to the thread.
    « Last Edit: July 28, 2015, 12:16:24 PM by NorrinRadd »

    foxidrive



      Specialist
    • Thanked: 268
    • Experience: Experienced
    • OS: Windows 8
    Re: xcopy problem from one mem card > PC > new mem card
    « Reply #19 on: July 28, 2015, 02:17:52 PM »
     :D


    foxidrive



      Specialist
    • Thanked: 268
    • Experience: Experienced
    • OS: Windows 8
    Re: xcopy problem from one mem card > PC > new mem card
    « Reply #20 on: July 29, 2015, 03:45:14 AM »
    I'm replying here to clear the air in this thread for future readers that may be misled by NorrinRadd's misunderstanding, and his total lack of ability to test the command lines, to confirm for himself if what he believes is true.

    His claim is that this command line will copy every file from a source to target  - where in actual fact it will fail to copy hidden and system files - as pointed out by BC_Programmer

    xcopy G:\*.* /S /E /V

    This command line will copy exactly the same files, because /E does the same as /S but also copies empty folders - and adding /S does nothing extra.

    xcopy G:\*.* /E

    The /V switch does absolutely nothing except to check if each copied file is the same size - it doesn't verify the file contents that are being copied, despite being called the verify switch.

    The commands above will not give a complete copy of all files regardless of file attributes.

    The command line I provided for modern versions of Windows will create a mirror backup of all files including hidden and system and empty folders - and removes any extra or different files or folders on the target location (which is F: below)

    robocopy e:\ f:\ /mir

    We can only assume NorrinRadd's first failed attempt is due to hidden and system files, but it could have been a number of unrelated reasons, such as aborting the batch file/command line for one.

    If he runs a test using the commands above then he can verify the truth of what I say for himself.
    I won't hold my breath. :D
    « Last Edit: July 29, 2015, 04:07:11 AM by foxidrive »

    BC_Programmer


      Mastermind
    • Typing is no substitute for thinking.
    • Thanked: 1140
      • Yes
      • Yes
      • BC-Programming.com
    • Certifications: List
    • Computer: Specs
    • Experience: Beginner
    • OS: Windows 11
    Re: xcopy problem from one mem card > PC > new mem card
    « Reply #21 on: July 29, 2015, 09:20:10 AM »
    We can only assume NorrinRadd's first failed attempt is due to hidden and system files, but it could have been a number of unrelated reasons, such as aborting the batch file/command line for one.
    The original Command Line did in fact have the /H switch, so my "theory" is that it was the typo in the target specification, as I noted. Though it was stated they tried all sorts of combinations (which they didn't really describe at the time), it would be consistent with what we've been told, I think; the only alternative would be xcopy ignoring switches and just doing what it wants.

    1. standard copy from Windows Explorer Copy/Paste. This wouldn't copy hidden or system files (uness they were set to be visible, I think). This would be seen.
    2. Original xcopy attempts. The command lines they used would copy to an L directory/folder, and not to the L: drive. The files on L: would remain unchanged, still being the same as the results from the Copy Paste, since the files would not be being copied there.
    3. the "Fixed" one actually working as claimed leaves me rather stymied. It seems likely they fiddled with it a bit, and that it was not the actual command they ran, but rather a variant where they added extra switches.
    I was trying to dereference Null Pointers before it was cool.

    foxidrive



      Specialist
    • Thanked: 268
    • Experience: Experienced
    • OS: Windows 8
    Re: xcopy problem from one mem card > PC > new mem card
    « Reply #22 on: July 29, 2015, 02:30:48 PM »
    The original Command Line did in fact have the /H switch, so my "theory" is that it was the typo in the target specification, as I noted.

    2. Original xcopy attempts. The command lines they used would copy to an L directory/folder, and not to the L: drive. The files on L: would remain unchanged, still being the same as the results from the Copy Paste, since the files would not be being copied there.

    I saw when you mentioned that and forgot to have a look.
    I just did so and giggled as you're quite right and the fellow had no clue, yet got all aggressive about everything.

    Quote
    3. the "Fixed" one actually working as claimed leaves me rather stymied. It seems likely they fiddled with it a bit, and that it was not the actual command they ran, but rather a variant where they added extra switches.

    Yeah.  Finger trouble. 

    NorrinRadd

      Topic Starter


      Greenhorn

      • Experience: Experienced
      • OS: Windows Vista
      Re: xcopy problem from one mem card > PC > new mem card
      « Reply #23 on: August 01, 2015, 12:18:57 AM »
      The original Command Line did in fact have the /H switch, so my "theory" is that it was the typo in the target specification, as I noted. Though it was stated they tried all sorts of combinations (which they didn't really describe at the time), it would be consistent with what we've been told, I think; the only alternative would be xcopy ignoring switches and just doing what it wants.

      1. standard copy from Windows Explorer Copy/Paste. This wouldn't copy hidden or system files (uness they were set to be visible, I think). This would be seen.

      2. Original xcopy attempts. The command lines they used would copy to an L directory/folder, and not to the L: drive. The files on L: would remain unchanged, still being the same as the results from the Copy Paste, since the files would not be being copied there.

      3. the "Fixed" one actually working as claimed leaves me rather stymied. It seems likely they fiddled with it a bit, and that it was not the actual command they ran, but rather a variant where they added extra switches.

      Thanks BC_Programmer, I will try to address your points:
       
      The variations I tried I did describe, perhaps not clearly, where I mentioned the "L" vs. "L:" and "\L" and  "\L:" permutations.  I didn’t reformat the card after each attempt, and ran the commands one after the other, so that might account for your theory assertion.

      In the end I reformatted the card once more before using the tomshardware command.  I didn’t fiddle with that and ran it exactly as posted. No alleged “Finger trouble”.

      ================================

      Two other things – format and DIR
      I mentioned there is another consideration, and wonder why no one asked or if it is in fact a factor - the manner of formatting the card before the copies. 

      Before the tomshardware string I tried long form format and quick format, and at the time wondered if there was anything to consider regarding FAT vs. NTFS or some other formatting and if that was the cause of the initial problem.  The last format I did before the successful command was a quick format.

      The xcopy command output said 24k files were copied, after that the DIR command showed far less, I put it out there to see if maybe I was doing something wrong with the DIR command to show all the files. No one said anything about it so I guess not.

      ================================

      So hey, foxidrive, had I seen your robocopy command before the tomshardware one I would have certainly tried it out, it was just down to the timing.  After that there was no reason to do it again with a different command.  I started using the phone and the contents of the card changed from that point.

      Calling me out with “got all aggressive about everything” whilst peppering your responses with that amount of condescending and pejorative language “Claim” “You're welcome.” “thankfully”  “It's looking very much that way” ”total lack of ability” ”giggled”  “the fellow had no clue,” won't hold my breath”, etc. is a bit pot/kettle/black.

      I didn’t ‘claim’ anything – I stated the issue, posted what I tried, the failures, and the results.

      Though while putting on a negative spin on how I attempted and achieved what I set out to do and posturing yourself as Guardian Of Future Readers, there is nothing in my content that should mislead and certainly was not my intent - I  have been completely transparent in my purpose, my failed attempts, and what I did to resolve it.

      You seem to read into things that are not there - it may be an ego thing, a comprehension thing, or just pure misunderstanding.  You seem to struggle with this and look for opportunities to be adversarial and vitriolic.  And so I respond in kind.

      The commands above will not give a complete copy of all files regardless of file attributes. 

      I admitted then I didn’t know why what I tried at first didn’t work to try and understand it, and I admit now I don’t know why what I did in the end worked.  It is less “what he believes is true” and more the results.

      The noob in me bows to your DOS prowess, but unless what DIR is telling me is wrong and hence my question at the top of this post, the reality is all the files, dirs and permissions came over with that tomshardware command.

      While I had an interest to understand the commands better while I still had the problem, once it was solved I no longer had that interest, and for future card upgrades I would most likely use the same command or try that robocopy suggestion.

      So questions to the almighty foxidrive:  did you try these commands, do DIRs after them, and get different results?  Why did the tomshardware advice work the first time on a freshly-formatted card?

      As the test can be done with any memory card, there is no real reason for me with my cards to do it.

      When you can answer these then you can take the pebble from my hand.

      You may well be a Good Guy on this forum, but as pretty much everyone puts their foot in it at some point, it’s about how you pull your foot out that people will remember you for.   

      BC_Programmer


        Mastermind
      • Typing is no substitute for thinking.
      • Thanked: 1140
        • Yes
        • Yes
        • BC-Programming.com
      • Certifications: List
      • Computer: Specs
      • Experience: Beginner
      • OS: Windows 11
      Re: xcopy problem from one mem card > PC > new mem card
      « Reply #24 on: August 01, 2015, 09:00:29 AM »
      Formatting option wouldn't really matter- drive should be clear or equivalent either way. NTFS/FAT32 might make a difference since in your original command you specified the option to copy ACLs (permissions) which is only supported on NTFS, though I doubt that would cause files to just not be copied.

      The xcopy command output said 24k files were copied, after that the DIR command showed far less, I put it out there to see if maybe I was doing something wrong with the DIR command to show all the files. No one said anything about it so I guess not.


      Actually I had written about that originally but I removed it because I thought it looked douchey, but the command in the OP, "dir /ad-h"  will explicitly show everything except hidden files, as seen in the dir /? (- being a prefix meant to exclude an attribute). I had forgotten about it myself and moved forward with the assumption that the files were not being copied when it may be that the dir command you were using that was not showing them. After your original reply regarding the L/L:/etc. I must admit I thought of it again but I at that point I perhaps unfairly expected you might say you had tried other combinations as well in the same manner.


      Quote
      did you try these commands, do DIRs after them, and get different results?  Why did the tomshardware advice work the first time on a freshly-formatted card?

      As the test can be done with any memory card, there is no real reason for me with my cards to do it.

      When you can answer these then you can take the pebble from my hand.

      I know this isn't directed at me but I did (as best I could) and that is what led to my original L versus L: stuff. Now, that said, I couldn't nearly reproduce your situation because I don't have any Smartphones or such that would have a similar folder structure, so the best I could do was with fake data with a few hidden files and such.

      Really, the command you listed as working explicitly doesn't copy hidden or system files, thus why we aren't able to "accept" that it was a solution, so We (well, I'm) thinking perhaps another factor led to it seeming to work. Possibly changing how you verified the file copy?
      I was trying to dereference Null Pointers before it was cool.

      NorrinRadd

        Topic Starter


        Greenhorn

        • Experience: Experienced
        • OS: Windows Vista
        Re: xcopy problem from one mem card > PC > new mem card
        « Reply #25 on: August 03, 2015, 08:00:33 AM »
        Formatting option wouldn't really matter- drive should be clear or equivalent either way. NTFS/FAT32 might make a difference since in your original command you specified the option to copy ACLs (permissions) which is only supported on NTFS, though I doubt that would cause files to just not be copied.
        Thansk for clearing that up, and what confuses it more is that I first copied using cut&paste which invoked TeraCopy, then for each or almost each successive attempt I created a new Dir on my PC to get the files there.

        Now I can't remember if I tried a copy from one card to another card and bypassing the PC.

        One other thing is as I tried so many options I'm not sure if one of the formats I did was on the phone itself, not mounted by the PC and run from a cmd window.

        Actually I had written about that originally but I removed it because I thought it looked douchey, but the command in the OP, "dir /ad-h"  will explicitly show everything except hidden files, as seen in the dir /? (- being a prefix meant to exclude an attribute). I had forgotten about it myself and moved forward with the assumption that the files were not being copied when it may be that the dir command you were using that was not showing them. After your original reply regarding the L/L:/etc. I must admit I thought of it again but I at that point I perhaps unfairly expected you might say you had tried other combinations as well in the same manner.

        I did try a few Dir switches, but aside from that, what confuses me is why the copy command in the OP has the output that 24k files got copied over to the PC folder, but when I DIRed that folder there was less than half were there (I think I still have that output) and the overall size was only !3gb out of the !6gb resident on that card.

        I know this isn't directed at me but I did (as best I could) and that is what led to my original L versus L: stuff. Now, that said, I couldn't nearly reproduce your situation because I don't have any Smartphones or such that would have a similar folder structure, so the best I could do was with fake data with a few hidden files and such.

        Well I do still have the original 8gb card with the original content. I don't have another card beside the one in my phone and I don't want to mess with that now, but could try copying to PC in a new folder.


        Really, the command you listed as working explicitly doesn't copy hidden or system files, thus why we aren't able to "accept" that it was a solution, so We (well, I'm) thinking perhaps another factor led to it seeming to work. Possibly changing how you verified the file copy?
        Yes I think that is possible, I should have that output
        « Last Edit: August 03, 2015, 08:15:07 AM by NorrinRadd »