I made a backup of entire file trees onto DVD. Of course, they are
read-only. This means the write permission info is lost. When I copy
the tree back to a local hard drive, I have no choice but to
recursively grant write-permission throughout the entire file tree in
order to be able to use it. The only problem is that some files/
folders in the original file tree did not have write permission, and
probably for good situation-specific reasons. I just don't recall
which ones.
This must be a very common problem. How does one deal with that when
migrating entire file trees back onto local hard drives from backup
media (DVD or CD)? I know that I can preserve the permissions in the
backed-up files if I created a compressed tar file or zip file, but I
deliberately avoided that to make it easy to access individual files
and subtrees in the backup, and to avoid creating large monolithic
archive files that aggregate entire [sub]trees. The entire subtree is
lost if the archive file is corrupted.
Hopefully, there is a solution that doesn't do away with the read-only
attribute of the backup medium. Otherwise, the backup becomes
vulnerable to change.
Mister.Fred.Ma@gmail.com wrote:
> I made a backup of entire file trees onto DVD. Of course, they are
> read-only. This means the write permission info is lost. When I copy
> the tree back to a local hard drive, I have no choice but to
> recursively grant write-permission throughout the entire file tree in
> order to be able to use it. The only problem is that some files/
> folders in the original file tree did not have write permission, and
> probably for good situation-specific reasons. I just don't recall
> which ones.
>
> This must be a very common problem. How does one deal with that when
> migrating entire file trees back onto local hard drives from backup
> media (DVD or CD)? I know that I can preserve the permissions in the
> backed-up files if I created a compressed tar file or zip file, but I
> deliberately avoided that to make it easy to access individual files
> and subtrees in the backup, and to avoid creating large monolithic
> archive files that aggregate entire [sub]trees. The entire subtree is
> lost if the archive file is corrupted.
>
> Hopefully, there is a solution that doesn't do away with the read-only
> attribute of the backup medium. Otherwise, the backup becomes
> vulnerable to change.
>
> Thanks.
>
You go to command prompt, navigate to top directory and type:
attrib /s -r
There are probably utilities that do same thing, but what could be easier.
Dave Cohen
Mister.Fred.Ma@gmail.com wrote:
> I made a backup of entire file trees onto DVD. Of course, they are
> read-only. This means the write permission info is lost. When I copy
> the tree back to a local hard drive, I have no choice but to
> recursively grant write-permission throughout the entire file tree in
> order to be able to use it. The only problem is that some files/
> folders in the original file tree did not have write permission, and
> probably for good situation-specific reasons. I just don't recall
> which ones.
>
> This must be a very common problem. How does one deal with that when
> migrating entire file trees back onto local hard drives from backup
> media (DVD or CD)? I know that I can preserve the permissions in the
> backed-up files if I created a compressed tar file or zip file, but I
> deliberately avoided that to make it easy to access individual files
> and subtrees in the backup, and to avoid creating large monolithic
> archive files that aggregate entire [sub]trees. The entire subtree is
> lost if the archive file is corrupted.
>
> Hopefully, there is a solution that doesn't do away with the read-only
> attribute of the backup medium. Otherwise, the backup becomes
> vulnerable to change.
Making files transferred from mastered optical media Read-Only is
consistent with the specs. Despite that, in XP (and, I assume, VISTA)
they are read as permitting write - whether or not they were originally
read-only.
An easy solution to your problem is to archive the tree (ZIP, RAR, etc.)
retaining folder structure. That will retain the original attributes.
On Oct 5, 12:01 pm, Dave Cohen <u...@example.net> wrote:
> Mister.Fred...@gmail.com wrote:
> > I made a backup of entire file trees onto DVD. Of course, they are
> > read-only. This means the write permission info is lost. When I copy
> > the tree back to a local hard drive, I have no choice but to
> > recursively grant write-permission throughout the entire file tree in
> > order to be able to use it. The only problem is that some files/
> > folders in the original file tree did not have write permission, and
> > probably for good situation-specific reasons. I just don't recall
> > which ones.
>
> > This must be a very common problem. How does one deal with that when
> > migrating entire file trees back onto local hard drives from backup
> > media (DVD or CD)? I know that I can preserve the permissions in the
> > backed-up files if I created a compressed tar file or zip file, but I
> > deliberately avoided that to make it easy to access individual files
> > and subtrees in the backup, and to avoid creating large monolithic
> > archive files that aggregate entire [sub]trees. The entire subtree is
> > lost if the archive file is corrupted.
>
> > Hopefully, there is a solution that doesn't do away with the read-only
> > attribute of the backup medium. Otherwise, the backup becomes
> > vulnerable to change.
>
> > Thanks.
>
> You go to command prompt, navigate to top directory and type:
> attrib /s -r
> There are probably utilities that do same thing, but what could be easier.
Dave,
I typed
atttrib /?
It seems to me that your command also recursively grants write
permission throughout the file tree. Hope I've understood...
On Oct 5, 2:18 pm, Mike Richter <mrich...@cpl.net> wrote:
> Mister.Fred...@gmail.com wrote:
> > I made a backup of entire file trees onto DVD. Of course, they are
> > read-only. This means the write permission info is lost. When I copy
> > the tree back to a local hard drive, I have no choice but to
> > recursively grant write-permission throughout the entire file tree in
> > order to be able to use it. The only problem is that some files/
> > folders in the original file tree did not have write permission, and
> > probably for good situation-specific reasons. I just don't recall
> > which ones.
>
> > This must be a very common problem. How does one deal with that when
> > migrating entire file trees back onto local hard drives from backup
> > media (DVD or CD)? I know that I can preserve the permissions in the
> > backed-up files if I created a compressed tar file or zip file, but I
> > deliberately avoided that to make it easy to access individual files
> > and subtrees in the backup, and to avoid creating large monolithic
> > archive files that aggregate entire [sub]trees. The entire subtree is
> > lost if the archive file is corrupted.
>
> > Hopefully, there is a solution that doesn't do away with the read-only
> > attribute of the backup medium. Otherwise, the backup becomes
> > vulnerable to change.
>
> Making files transferred from mastered optical media Read-Only is
> consistent with the specs. Despite that, in XP (and, I assume, VISTA)
> they are read as permitting write - whether or not they were originally
> read-only.
They were read-only after uploading from CD onto the hard drive.
However, even if the uploaded files defaulted to not-read-only, this
still contains the problem of lost [not]readonly attribute.
> An easy solution to your problem is to archive the tree (ZIP, RAR, etc.)
> retaining folder structure. That will retain the original attributes.
>
> Mike
> --
> mrich...@cpl.nethttp://www.mrichter.com/
Mister.Fred.Ma@gmail.com wrote:
> On Oct 5, 12:01 pm, Dave Cohen <u...@example.net> wrote:
>> Mister.Fred...@gmail.com wrote:
>>> I made a backup of entire file trees onto DVD. Of course, they are
>>> read-only. This means the write permission info is lost. When I copy
>>> the tree back to a local hard drive, I have no choice but to
>>> recursively grant write-permission throughout the entire file tree in
>>> order to be able to use it. The only problem is that some files/
>>> folders in the original file tree did not have write permission, and
>>> probably for good situation-specific reasons. I just don't recall
>>> which ones.
>>> This must be a very common problem. How does one deal with that when
>>> migrating entire file trees back onto local hard drives from backup
>>> media (DVD or CD)? I know that I can preserve the permissions in the
>>> backed-up files if I created a compressed tar file or zip file, but I
>>> deliberately avoided that to make it easy to access individual files
>>> and subtrees in the backup, and to avoid creating large monolithic
>>> archive files that aggregate entire [sub]trees. The entire subtree is
>>> lost if the archive file is corrupted.
>>> Hopefully, there is a solution that doesn't do away with the read-only
>>> attribute of the backup medium. Otherwise, the backup becomes
>>> vulnerable to change.
>>> Thanks.
>> You go to command prompt, navigate to top directory and type:
>> attrib /s -r
>> There are probably utilities that do same thing, but what could be easier.
>
> Dave,
>
> I typed
>
> atttrib /?
>
> It seems to me that your command also recursively grants write
> permission throughout the file tree. Hope I've understood...
>
> Fred
>
Yes, that's the /s switch. Current directory and everything below (I
assume that is what you want). Of course you can confine the changes to
current directory by omitting the switch.
Dave Cohen
On Oct 6, 1:03 pm, Dave Cohen <u...@example.net> wrote:
> Mister.Fred...@gmail.com wrote:
> > On Oct 5, 12:01 pm, Dave Cohen <u...@example.net> wrote:
> >> Mister.Fred...@gmail.com wrote:
> >>> I made a backup of entire file trees onto DVD. Of course, they are
> >>> read-only. This means the write permission info is lost. When I copy
> >>> the tree back to a local hard drive, I have no choice but to
> >>> recursively grant write-permission throughout the entire file tree in
> >>> order to be able to use it. The only problem is that some files/
> >>> folders in the original file tree did not have write permission, and
> >>> probably for good situation-specific reasons. I just don't recall
> >>> which ones.
> >>> This must be a very common problem. How does one deal with that when
> >>> migrating entire file trees back onto local hard drives from backup
> >>> media (DVD or CD)? I know that I can preserve the permissions in the
> >>> backed-up files if I created a compressed tar file or zip file, but I
> >>> deliberately avoided that to make it easy to access individual files
> >>> and subtrees in the backup, and to avoid creating large monolithic
> >>> archive files that aggregate entire [sub]trees. The entire subtree is
> >>> lost if the archive file is corrupted.
> >>> Hopefully, there is a solution that doesn't do away with the read-only
> >>> attribute of the backup medium. Otherwise, the backup becomes
> >>> vulnerable to change.
> >>> Thanks.
> >> You go to command prompt, navigate to top directory and type:
> >> attrib /s -r
> >> There are probably utilities that do same thing, but what could be easier.
>
> > Dave,
>
> > I typed
>
> > atttrib /?
>
> > It seems to me that your command also recursively grants write
> > permission throughout the file tree. Hope I've understood...
>
> Yes, that's the /s switch. Current directory and everything below (I
> assume that is what you want). Of course you can confine the changes to
> current directory by omitting the switch.
That's what I'm doing right now. The problem is that all the files
exist as read-only, since the the DVD is write-once media. This means
that the original permissions are lost. Making the whole file tree
writable is a highly suboptimum solution. I was wondering if there
was a way to keep the permissions of the original files, even though
they exist on write-once media. That is, if a file is writable before
being written to DVD, have the file retains the writable permission
even though it isn't writable. This is only so that when it is
uploaded back to a hard drive, the proper permissions are retained.
Again, I know you can preserved the while file tree, and the file
permissions, by using tar or zip, but I was hoping to avoid packing
the file tree into an aggregate file so as to simply access to the
files.
Files from DVD backup are Read-only 
Linear Mode
