robocopy and ntfs to fat32

Well I wrote some time back concerning robocopy. I was given advice and
I still have that saved for a fat32 to fat32 partition exchange. That's
fine. Now I have a USB DVD-RW and can't seem to format a small fat32 with
windows. How can I use robocoy to move everything from ntfs to a fat32?

Bill

On Fri, 9 Oct 2015 18:46:42 -0400, "Bill Cunningham"
wrote:

Well I wrote some time back concerning robocopy. I was given advice and
I still have that saved for a fat32 to fat32 partition exchange. That's
fine. Now I have a USB DVD-RW and can't seem to format a small fat32 with
windows. How can I use robocoy to move everything from ntfs to a fat32?



I know next to nothing about robocopy, but in general what the from
and to files system are is irrelevant. You can move from any of then
to any other without doing anything special.

Ken Blake, MVP wrote:
On Fri, 9 Oct 2015 18:46:42 -0400, "Bill Cunningham"
wrote:

Well I wrote some time back concerning robocopy. I was given advice and
I still have that saved for a fat32 to fat32 partition exchange. That's
fine. Now I have a USB DVD-RW and can't seem to format a small fat32 with
windows. How can I use robocoy to move everything from ntfs to a fat32?



I know next to nothing about robocopy, but in general what the from
and to files system are is irrelevant. You can move from any of then
to any other without doing anything special.

Except if the discussion shifts to "permissions".

The destination in this case is FAT32, which doesn't have permissions.

The source is NTFS, and you would need permission to read
the items off the source. Say for example, there was
a System Volume Information folder, you might get
permission denied on the source.

While this article is not a manual page for Robocopy, it
shows how the thinking changed between the WinXP (XP026)
version and the Vista version.

http://blogs.technet.com/b/filecab/a...rmissions.aspx

You can check the summary in the Command Prompt window, and
look for "failed" items when the command has finished executing.
Specifying a log file for all the output from Robocopy, might
even show which file or folders got ignored due to permissions.
The log file is necessary, as the Command Prompt won't have
enough history buffer for all of it.

Paul

"Paul" wrote in message
...

Except if the discussion shifts to "permissions".

The destination in this case is FAT32, which doesn't have permissions.

The source is NTFS, and you would need permission to read
the items off the source. Say for example, there was
a System Volume Information folder, you might get
permission denied on the source.

While this article is not a manual page for Robocopy, it
shows how the thinking changed between the WinXP (XP026)
version and the Vista version.

http://blogs.technet.com/b/filecab/a...rmissions.aspx

You can check the summary in the Command Prompt window, and
look for "failed" items when the command has finished executing.
Specifying a log file for all the output from Robocopy, might
even show which file or folders got ignored due to permissions.
The log file is necessary, as the Command Prompt won't have
enough history buffer for all of it.

Thanks much Paul! I know you know robocopy well. Your instructions I
have were concerning fat32 to fat32 but that's not my situation now. I
checked the log file and indeed, some files were not copied. So wuld I need
to copy these things manually? I do not know if this would be possible to
copy ntfs and it's permissions to fat32 via a linux OS. So I want to do this
right. Is there just no way to get robocopy to copy from ntfs to fat32 all
necessary permissions to have a working OS?

Bill

"Paul" wrote in message
...
Ken Blake, MVP wrote:
On Fri, 9 Oct 2015 18:46:42 -0400, "Bill Cunningham"
wrote:

Well I wrote some time back concerning robocopy. I was given advice
and I still have that saved for a fat32 to fat32 partition exchange.
That's fine. Now I have a USB DVD-RW and can't seem to format a small
fat32 with windows. How can I use robocoy to move everything from ntfs
to a fat32?



I know next to nothing about robocopy, but in general what the from
and to files system are is irrelevant. You can move from any of then
to any other without doing anything special.

Except if the discussion shifts to "permissions".

The destination in this case is FAT32, which doesn't have permissions.

The source is NTFS, and you would need permission to read
the items off the source. Say for example, there was
a System Volume Information folder, you might get
permission denied on the source.

While this article is not a manual page for Robocopy, it
shows how the thinking changed between the WinXP (XP026)
version and the Vista version.

http://blogs.technet.com/b/filecab/a...rmissions.aspx

You can check the summary in the Command Prompt window, and
look for "failed" items when the command has finished executing.
Specifying a log file for all the output from Robocopy, might
even show which file or folders got ignored due to permissions.
The log file is necessary, as the Command Prompt won't have
enough history buffer for all of it.

I'm not quite sure what to glean from the link. I know /sec and even
/secfix can be necessary. I copied Documents and Settings to another
partition that is fat32. 12 files were not copied. Files that were in use.
ntuser.log.dat or something like that. ntuser.dat or so. System files in
memory. How would you copy them?

Bill

In microsoft.public.windowsxp.general, on Sat, 10 Oct 2015 15:13:17
-0400, "Bill Cunningham" wrote:


"Paul" wrote in message
...

Except if the discussion shifts to "permissions".

The destination in this case is FAT32, which doesn't have permissions.

The source is NTFS, and you would need permission to read
the items off the source. Say for example, there was
a System Volume Information folder, you might get
permission denied on the source.

While this article is not a manual page for Robocopy, it
shows how the thinking changed between the WinXP (XP026)
version and the Vista version.

http://blogs.technet.com/b/filecab/a...rmissions.aspx

You can check the summary in the Command Prompt window, and
look for "failed" items when the command has finished executing.
Specifying a log file for all the output from Robocopy, might
even show which file or folders got ignored due to permissions.
The log file is necessary, as the Command Prompt won't have
enough history buffer for all of it.

Thanks much Paul! I know you know robocopy well. Your instructions I
have were concerning fat32 to fat32 but that's not my situation now. I
checked the log file and indeed, some files were not copied. So wuld I need
to copy these things manually? I do not know if this would be possible to
copy ntfs and it's permissions to fat32 via a linux OS. So I want to do this
right. Is there just no way to get robocopy to copy from ntfs to fat32 all
necessary permissions to have a working OS?

Bill

I'm still confused by all this myself, but I've gotten the impression
the only way to copy some files is have another partition with another
copy of an OS so that neither from- nor to-partitions are the Windows
system partition, and iiuc no permissions are needed??????

Bill Cunningham wrote:
"Paul" wrote in message
...

Except if the discussion shifts to "permissions".

The destination in this case is FAT32, which doesn't have permissions.

The source is NTFS, and you would need permission to read
the items off the source. Say for example, there was
a System Volume Information folder, you might get
permission denied on the source.

While this article is not a manual page for Robocopy, it
shows how the thinking changed between the WinXP (XP026)
version and the Vista version.

http://blogs.technet.com/b/filecab/a...rmissions.aspx

You can check the summary in the Command Prompt window, and
look for "failed" items when the command has finished executing.
Specifying a log file for all the output from Robocopy, might
even show which file or folders got ignored due to permissions.
The log file is necessary, as the Command Prompt won't have
enough history buffer for all of it.

Thanks much Paul! I know you know robocopy well. Your instructions I
have were concerning fat32 to fat32 but that's not my situation now. I
checked the log file and indeed, some files were not copied. So wuld I need
to copy these things manually? I do not know if this would be possible to
copy ntfs and it's permissions to fat32 via a linux OS. So I want to do this
right. Is there just no way to get robocopy to copy from ntfs to fat32 all
necessary permissions to have a working OS?

Bill

AFAIK, FAT32 has attributes but not permissions.
It would be nice if the attributes were preserved, but I haven't
experimented with all possible combinations of file system types,
so don't know what happens in detail.

Since FAT32 doesn't have permissions, there is no place to store
that information.

The OS supports (a rather miserable) FAT32 to NTFS convert
utility. But I don't know of a way to go from NTFS to FAT32.
Google says there are some third-party utilities for that,
but you'd need to check the results pretty carefully.
They're not likely to have as detailed a log as you get with Robocopy.

I think I would be going back to the robocopy log file,
find out how extensive the damage is, before getting too excited.
If it won't copy System Volume Information, that's not a big deal.
When the new copy of Windows boots up (on its own without the
original disk present), you can turn System Restore off and on
again, and that should clean out a fair bit of System Volume Information.
And since VSS doesn't keep persistent files in there, you don't
have to worry about that. And losing some CHKDSK log file that
is sitting in there, isn't a big deal either. So not copying
a folder like that, isn't a big deal as far as the function
of the OS goes. It's true you don't get to keep your
System Restore points, but then, you still have the
old OS disk if you need it for emergencies.

It's possible Linux would do a good job. Again, I don't know if
attributes are preserved. Certainly permissions are not
preserved, but we don't care about that anyway, as the
target partition is FAT32. Only the treatment of the
attributes would be worth verifying.

It's a situation ripe with experimental possibilities.
Many routes, lots of testing to do.

When you're finished, you'll likely need a "fixboot"
for that FAT32 partition (done from Recovery Console).
And if you aren't careful, probably setting the
boot flag on the partition, for that disk.

Paul

Bill Cunningham wrote:
"Paul" wrote in message
...
Ken Blake, MVP wrote:
On Fri, 9 Oct 2015 18:46:42 -0400, "Bill Cunningham"
wrote:

Well I wrote some time back concerning robocopy. I was given advice
and I still have that saved for a fat32 to fat32 partition exchange.
That's fine. Now I have a USB DVD-RW and can't seem to format a small
fat32 with windows. How can I use robocoy to move everything from ntfs
to a fat32?


I know next to nothing about robocopy, but in general what the from
and to files system are is irrelevant. You can move from any of then
to any other without doing anything special.
Except if the discussion shifts to "permissions".

The destination in this case is FAT32, which doesn't have permissions.

The source is NTFS, and you would need permission to read
the items off the source. Say for example, there was
a System Volume Information folder, you might get
permission denied on the source.

While this article is not a manual page for Robocopy, it
shows how the thinking changed between the WinXP (XP026)
version and the Vista version.

http://blogs.technet.com/b/filecab/a...rmissions.aspx

You can check the summary in the Command Prompt window, and
look for "failed" items when the command has finished executing.
Specifying a log file for all the output from Robocopy, might
even show which file or folders got ignored due to permissions.
The log file is necessary, as the Command Prompt won't have
enough history buffer for all of it.

I'm not quite sure what to glean from the link. I know /sec and even
/secfix can be necessary. I copied Documents and Settings to another
partition that is fat32. 12 files were not copied. Files that were in use.
ntuser.log.dat or something like that. ntuser.dat or so. System files in
memory. How would you copy them?

Bill

Well, to start, you don't try to copy a running OS :-)

When I copy my WinXP C: drive, I boot Win2K and do the
copying while Win2K is running. Since the WinXP files
are "at rest" and not busy, the copy works a lot better.
Win2K is my "maintenance" OS, for things like that.
I run Robocopy from Win2K.

There is supposed to be some way to cause a shadow copy
of C: to be made with VSS, but I haven't personally tried that.
The VSS on WinXP allows creating a shadow of a partition, but
it doesn't survive a reboot. Whereas other OSes have more
fully developed VSS implementations. In any case, there is
supposed to be some way for a user to create a shadow copy,
which "freezes" a copy of the OS for copying purposes. And you
would not have to shut down WinXP or reboot or anything, if
you could get that working.

Copying my WinXP while Win2K is booted, is a *lot* simpler.

Paul

From: "Bill Cunningham"


"Paul" wrote in message
...
Ken Blake, MVP wrote:
On Fri, 9 Oct 2015 18:46:42 -0400, "Bill Cunningham"
wrote:

Well I wrote some time back concerning robocopy. I was given advice
and I still have that saved for a fat32 to fat32 partition exchange.
That's fine. Now I have a USB DVD-RW and can't seem to format a small
fat32 with windows. How can I use robocoy to move everything from ntfs
to a fat32?

I know next to nothing about robocopy, but in general what the from
and to files system are is irrelevant. You can move from any of then
to any other without doing anything special.

Except if the discussion shifts to "permissions".

The destination in this case is FAT32, which doesn't have permissions.

The source is NTFS, and you would need permission to read
the items off the source. Say for example, there was
a System Volume Information folder, you might get
permission denied on the source.

While this article is not a manual page for Robocopy, it
shows how the thinking changed between the WinXP (XP026)
version and the Vista version.

http://blogs.technet.com/b/filecab/a...rmissions.aspx

You can check the summary in the Command Prompt window, and
look for "failed" items when the command has finished executing.
Specifying a log file for all the output from Robocopy, might
even show which file or folders got ignored due to permissions.
The log file is necessary, as the Command Prompt won't have
enough history buffer for all of it.

I'm not quite sure what to glean from the link. I know /sec and even
/secfix can be necessary. I copied Documents and Settings to another
partition that is fat32. 12 files were not copied. Files that were in use.
ntuser.log.dat or something like that. ntuser.dat or so. System files in
memory. How would you copy them?

Bill


You would have to reboot the system and logon to a different account with
administrative rights with the rights to access the files.

--
Dave
Multi-AV Scanning Tool - http://multi-av.thespykiller.co.uk
http://www.pctipp.ch/downloads/dl/35905.asp

"Paul" wrote in message
...

Well, to start, you don't try to copy a running OS :-)

Yeah I wondered how you did it. But /copy:AT and /dcopy:T should be
enough shouldn't it to copy from a ntfs to fat 32.

When I copy my WinXP C: drive, I boot Win2K and do the
copying while Win2K is running. Since the WinXP files
are "at rest" and not busy, the copy works a lot better.
Win2K is my "maintenance" OS, for things like that.
I run Robocopy from Win2K.

There is supposed to be some way to cause a shadow copy
of C: to be made with VSS, but I haven't personally tried that.
The VSS on WinXP allows creating a shadow of a partition, but
it doesn't survive a reboot. Whereas other OSes have more
fully developed VSS implementations. In any case, there is
supposed to be some way for a user to create a shadow copy,
which "freezes" a copy of the OS for copying purposes. And you
would not have to shut down WinXP or reboot or anything, if
you could get that working.

Copying my WinXP while Win2K is booted, is a *lot* simpler.

What exactly is VSS? I run linux more than a copy of win2k that I have
but idk if it would copy all attributes for a fat32 partition.

Bill

Bill Cunningham wrote:
"Paul" wrote in message
...

Well, to start, you don't try to copy a running OS :-)

Yeah I wondered how you did it. But /copy:AT and /dcopy:T should be
enough shouldn't it to copy from a ntfs to fat 32.

When I copy my WinXP C: drive, I boot Win2K and do the
copying while Win2K is running. Since the WinXP files
are "at rest" and not busy, the copy works a lot better.
Win2K is my "maintenance" OS, for things like that.
I run Robocopy from Win2K.

There is supposed to be some way to cause a shadow copy
of C: to be made with VSS, but I haven't personally tried that.
The VSS on WinXP allows creating a shadow of a partition, but
it doesn't survive a reboot. Whereas other OSes have more
fully developed VSS implementations. In any case, there is
supposed to be some way for a user to create a shadow copy,
which "freezes" a copy of the OS for copying purposes. And you
would not have to shut down WinXP or reboot or anything, if
you could get that working.

Copying my WinXP while Win2K is booted, is a *lot* simpler.

What exactly is VSS? I run linux more than a copy of win2k that I have
but idk if it would copy all attributes for a fat32 partition.

https://en.wikipedia.org/wiki/Shadow_Copy

"A snapshot is a read-only point-in-time copy of the volume.
Snapshots allow the creation of consistent backups of a volume,
ensuring that the contents do not change and are not locked
while the backup is being made."

There are still situations where you might miss a file while
using that. For example, if you were using Microsoft Word,
you might consider exiting the program, before performing
a backup. A lot of regular backup programs use VSS,
freezing C: before copying it. While the backup is running,
the OS can save fresh files to C:, but they're handled by
differencing - meaning when there is a frozen copy of the OS,
any newly created material is a "delta" and thus the old sectors
if any, must be preserved for the "frozen" copy. So if you
edit a file and save it when the backup is half-way finished,
the backup ends up with the old copy of the file. And you would
need to wait until the next backup, to save a copy of the
new file. So when VSS takes a "snapshot", it's a point-in-time
snapshot, and the state of all files is preserved for usage by
some backup or copy operation.

Paul