Bug in 'msdos' file system?

Bug in 'msdos' file system?

Post by Steve Frampt » Thu, 25 Feb 1993 00:00:08



Hello!

I am running the TAMU .99p4 release of Linux. Wonderful!  But I did run
across what appears to be a serious bug last night while attempting to
copy a Linux (unix) file onto an 'msdos' mounted partition.

I mounted my DOS drive C: as:  mount -t msdos /dev/hda1 /dos/c:

No problem.  I could access my DOS files as if they were normal unix files.
I then tried to move a file over onto DOS:

mv /home/frampton/myfile.txt /dos/c:

The 'mv' seemed to finish, so I executed a 'sync'.  The 'sync' command seemed
to hang there.  In fact I had to log on using another pty and issue a ps
command.  Interestingly enough, the 'mv' and 'sync' commands were still in
the process list.  So I tried to 'kill' them off -- but they wouldn't budge.
This was even the case when I used the 'kill -9' option.  Talk about your
zombie processes!  :-)

Shutting down the system (with the 'shutdown' command) didn't seem to work,
as it probably issued another 'sync' which hung up again.  After a few
minutes, I rebooted.

Afterward, I couldn't even boot Linux anymore!  I had to use the boot disk
and run an 'efsck' command to clear things up (yes, I'm using the extended
file system).  Being fairly new to Linux, I had only but to agree with what
'efsck' suggested needed fixing.  I can only assume that things are back to
normal now (it *appears* to work now).

Anyway, is this a known bug with the extended file system, the 'msdos' file
system, or both?

Thanks...

--------------------------------------------------------------------


 
 
 

Bug in 'msdos' file system?

Post by Joseph R. Pann » Thu, 25 Feb 1993 05:19:22



>No problem.  I could access my DOS files as if they were normal unix files.
>I then tried to move a file over onto DOS:

>mv /home/frampton/myfile.txt /dos/c:

>The 'mv' seemed to finish, so I executed a 'sync'.  The 'sync' command seemed
>to hang there.

Without knowing the internals too well, my sense is telling me that it's
a BAD IDEA to move files between two file systems, especially between as
different ones as Linux and DOS has.  In cases like that the files
probably should be copied, not moved because I imagine mv leaves the
actual data in place and only relinks directory pointers to that data.
So, in your case, the myfile.txt data was probably staying on your Linux
partition while a directory pointer from Linux was attempted to be moved
to the DOS partition.  That sounds like a bad news to me!  

There is a way to do this right even in such situations by
performing really a cp and rm operation in place of inter-filesystem mv,
but that is probably not done in this case.

Anyway, when in doubt, do cp and rm; that should always work.

Joe Pannon

 
 
 

Bug in 'msdos' file system?

Post by Steve Frampt » Thu, 25 Feb 1993 11:20:40



:
: Without knowing the internals too well, my sense is telling me that it's
: a BAD IDEA to move files between two file systems, especially between as
: different ones as Linux and DOS has.  In cases like that the files
: probably should be copied, not moved because I imagine mv leaves the
: actual data in place and only relinks directory pointers to that data.

Ah.  Hadn't thought about something like that.  :-)  Guess it serves me
right, having embraced MS-DOS for so long.  :-(

Anyway, even 'efsck' couldn't help me.  I turned out that I had to reinstall
the OS -- and guess what?  Disk #10 is corrupted.  :-(  Oh well, version 1.0
must be due for release soon, isn't it?

As an aside, since Linux supports the 'msdos' file system, perhaps the
kernel in the future could recognize that a 'mv' is being attempted to a
different file system and act accordingly?

Also, for those who maintain the TAMU release:  more error checking is
required during the installation.  I got to diskette #10, and the installation
program bombed due to an unsupported compressed format or something like that.
This was more than likely a simple read error (since I have installed from
these disks before) that a quick retry might have been able to clear up.  :-(

Thanks for the explanation.

-------------------------------------------------------------------------
I am an android. It is not possible for me to be injured in that fashion.



 
 
 

Bug in 'msdos' file system?

Post by Steven Bairst » Thu, 25 Feb 1993 15:59:10



Quote:

>Without knowing the internals too well, my sense is telling me that it's
>a BAD IDEA to move files between two file systems, especially between as
>different ones as Linux and DOS has.  In cases like that the files
>probably should be copied, not moved because I imagine mv leaves the
>actual data in place and only relinks directory pointers to that data.

>...

>Anyway, when in doubt, do cp and rm; that should always work.

I do hope that this is not the case. mv should not just move the directory
across any file systems, especially not file systems of different types.
If this is the case, it is not the users fault, mv is severely broken.
If it is not the case, ignore this message.

                        Steve

--
Steven A. Bairstow                    * "There ain't no rules around here!

   BitNet : sab139 at psuvm.psu.edu   *      - Thomas Edison

 
 
 

Bug in 'msdos' file system?

Post by Andrew Haylet » Thu, 25 Feb 1993 23:55:31



: Without knowing the internals too well, my sense is telling me that it's
: a BAD IDEA to move files between two file systems, especially between as
: different ones as Linux and DOS has.  In cases like that the files
: probably should be copied, not moved because I imagine mv leaves the
: actual data in place and only relinks directory pointers to that data.

Hang on, there's some misinformation floating around here. 'mv' is
cleverer than that. If the destination is on a different file system
from the source, then 'mv' does a copy followed by an unlink. So the
alleged problem with the DOS FS is nothing to do either with wrong user
action or 'mv' behaviour. And no special kernel action required, either.

----

 
 
 

Bug in 'msdos' file system?

Post by Ed Sklada » Fri, 26 Feb 1993 02:28:30



|>
|> : Without knowing the internals too well, my sense is telling me that it's
|> : a BAD IDEA to move files between two file systems, especially between as
|> : different ones as Linux and DOS has.  In cases like that the files
|> : probably should be copied, not moved because I imagine mv leaves the
|> : actual data in place and only relinks directory pointers to that data.
|>
|> Hang on, there's some misinformation floating around here. 'mv' is
|> cleverer than that. If the destination is on a different file system
|> from the source, then 'mv' does a copy followed by an unlink. So the
|> alleged problem with the DOS FS is nothing to do either with wrong user
|> action or 'mv' behaviour. And no special kernel action required, either.

Correct, although much earlier versions of some Unix systems (like our Encore)
would print a message like "Can't mv files across filesystems".  You
still can't move whole directories across filesystems (in SunOS, at least).
Attempting this gets you this message:
        "mv: can't mv directories across file systems".
The problem is not in the mv command itself, or the user action.

--

  Paramax Systems, A Unisys Company |     UUCP: ...!gvls1!eds
  Valley Forge Laboratories         | Box 517, Paoli, PA  19301  USA

 
 
 

Bug in 'msdos' file system?

Post by Michael Wi » Fri, 26 Feb 1993 07:44:11


mv of course is a cp when you try it across filesystems/partitions.

Michael

 
 
 

Bug in 'msdos' file system?

Post by Gert Doeri » Sun, 28 Feb 1993 00:11:49



Quote:>>mv /home/frampton/myfile.txt /dos/c:

>Without knowing the internals too well, my sense is telling me that it's
>a BAD IDEA to move files between two file systems, especially between as
>different ones as Linux and DOS has.  In cases like that the files
>probably should be copied, not moved because I imagine mv leaves the
>actual data in place and only relinks directory pointers to that data.
>So, in your case, the myfile.txt data was probably staying on your Linux
>partition while a directory pointer from Linux was attempted to be moved
>to the DOS partition.  That sounds like a bad news to me!  

Rubbish.

mv cannot link anything to a different filesystem, so the file is copied
and deleted.

Quote:>There is a way to do this right even in such situations by
>performing really a cp and rm operation in place of inter-filesystem mv,
>but that is probably not done in this case.

That *is* done internally by all "mv" implementations I know about.

gert
--



 
 
 

Bug in 'msdos' file system?

Post by Stephen Tweed » Wed, 03 Mar 1993 08:05:09




>>No problem.  I could access my DOS files as if they were normal unix files.
>>I then tried to move a file over onto DOS:
>>mv /home/frampton/myfile.txt /dos/c:
>>The 'mv' seemed to finish, so I executed a 'sync'.  The 'sync' command seemed
>>to hang there.
> Without knowing the internals too well, my sense is telling me that it's
> a BAD IDEA to move files between two file systems, especially between as
> different ones as Linux and DOS has.  In cases like that the files
> probably should be copied, not moved because I imagine mv leaves the
> actual data in place and only relinks directory pointers to that data.
> So, in your case, the myfile.txt data was probably staying on your Linux
> partition while a directory pointer from Linux was attempted to be moved
> to the DOS partition.  That sounds like a bad news to me!  

The GNU implementation of mv detects cross-device renames and copies
the files instead, automatically.  Even if it didn't, the kernel
rename() system call will report an error if you attempt to move
between devices.  In neither case should you expect a crash.  It looks
as if it might indeed be a dosfs problem - there is a new version
(0.10) available (I think that it is on sunsite.unc.edu, at least)
which corrects a few problems; this might help.

Cheers,
 Stephen Tweedie.
---

Department of Computer Science, Edinburgh University, Scotland.

 
 
 

1. msdos fs doesn't get file dates right - bug?

Under kernels 1.1.36 and 1.1.71, the MSDOS fs doesn't reflect the true
MS-DOS file date, as shown by a dir under MS-DOS and an ls -l of the
same file under Linux.

   TEST     PAR         1,506 11-30-94   9:09p

   -rw-r--r--   1 root     root         1506 Dec 20 13:09 test.par

If I touch the file under Linux, the MS-DOS file date becomes January
9th. This isn't acceptable behavior because I am moving source files
between Linux and DOS and these date changes confuse make.

Interestingly enough, the _minute_ always seems to remain correct.  Here
is my fstab:

/dev/hda1 swap        swap        defaults
/dev/hda2 /           ext2        defaults
/dev/hda3 /C          msdos       defaults,noexec
/dev/hdb1 /D          msdos       defaults,noexec,conv=auto
/dev/hdb2 /E          umsdos      defaults,noexec,conv=auto,gid=100,uid=501
none      /proc       proc        defaults

The same behavior is seen on /C /D and /E.  Any insigts, particularly if
this is some kind of configuration error, are greatly appreciated!

 -Matt
--
| Matt Armstrong

2. WP5.1 with dos-emu?

3. can't mount msdos file system

4. Adaptec 2640U2W install support

5. : users can't write to MSDOS file system

6. Default Session in KDM Login Screen

7. What's 'side effects' of Ksh built-ins?

8. Text is unreadable in X, why????

9. Problem running 'waisq' in 'chroot' file system

10. Is e2label 'dangerous' when done on a 'live' file system?

11. why can't I set 'rw' permissions to my msdos partition?

12. 'cat file' but only if 'file' exist

13. Coverting '.so' files to '.o' files