Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On Tue, 24 Oct 1995 mchale at zk3.dec.com wrote: > Is there a way to get the hidden files on an msdos partition viewable? > the files are on a large hard drive; > I looked at mtools but it cautions about using it on hard drives, and > it didnt seem to be what I wanted. > > I'm trying to backup the dos partion using tar.. > thanx > -jim > > Just a note on what you are trying to do. I backup both my DOS and Linux hard disks to Q150 cartridge tape using gnutar. In the case of DOS I use the ASPI (SCSI) tar port of gnutar. The Tar program ignores the DOS hidden files. This at first concerned me until I searched my DOS disc for hidden files ( dir /a:h /p /s) and discovered that on my system the only hidden files were the system IO.SYS and MSDOS.SYS files. These are files you would never backup but would be contained on a system rescue floppy. Incidentally, with Linux you can mount your DOS disc as a DOS type and view and manipulate any file except hidden ones as if they were Linux (Unix) files. In fact you can backup your files under DOS and restore them under Linux using gnutar and the mounted disc (file system). If you need to backup an unusual hidden file, you can change it to a normal one with the DOS ATTRIB command. and convert it back later. Barry ; Thu, 26 Oct 95 00:58:39 -0000 Date: Thu, 26 Oct 95 00:25:00 -0000 Message-ID: <8ebc506 at bilow.bilow.uu.ids.net> From: mikebw at bilow.bilow.uu.ids.net (Mike Bilow) Subject: Msdos hidden files viewable from linux? To: linux-sig at bcs.org X-Mailer: uugate 0.34 (OS/2 2.11) Sender: owner-linux-sig at bcs.org Precedence: bulk Reply-To: linux-sig at bcs.org Albert Cahalan wrote in a message to Mike Bilow: AC> Note that it is _impossible_ to correctly backup and restore AC> DOS system files without low-level disk access (read: AC> dangerous). The system bit means that the file is sensitive AC> to it's physical position on disk. The "system" bit does not imply this. In fact, as of DOS 4.0, only IO.SYS/IBMIO.COM was sensitive to physical location, and only the first cluster of it. MSDOS.SYS/IBMDOS.COM was also sensitive to physical location in DOS 3.3 and earlier. COMMAND.COM has never been sensitive to physical location. Worse, several DOS-based copy-protection schemes, such as Everlock, depend upon storing information about the physical location of files which do not have the "system" bit set or any other special marking present. As a result, backing up and restoring a program which uses the Everlock copy-protection scheme will prevent it from working, one of the things which has contributed to its demise. AC> As far as I know, you AC> can't back up and restore /boot or the kernel either, AC> because lilo gets confused. The same goes for msdos.sys and AC> io.sys. Maybe someone could write a program to fix the boot AC> sector to point to these files. DOS 4.0 and later actually works pefectly well if you clear the "hidden" and "system" bits from IO.SYS and MSDOS.SYS. You can even copy IO.SYS, MSDOS.SYS, and COMMAND.COM to a blank floppy and it will be bootable, as long as IO.SYS and MSDOS.SYS occupy the first two records of the root directory and IO.SYS starts in the first logical cluster of data space. The SYS.COM program makes sure that these conditions hold in addition to just copying the files. -- Mike
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |