On Tue, Sep 01, 2009 at 05:26:52AM -0500, Ron Johnson wrote: > On 2009-09-01 05:04, Daniel Dalton wrote: > >If I remount, I can't remove these effected files, the only way to fix > >things is to make use of fsck.vfat > > That seems to indicate that the error is on your mp3 player. Ok. So there isn't any way of checking if files stored on an ext3 fs are bad? Why do some files work ok and others don't? > > > -wa. > > ???? > > When looking at "man mkfs.vfat", I don't see those options. But > then, it's really an alias to MKDOSFS(8). Sorry, -w and -a I just used -wa > > >So, I can't continue syncing as if I get rid of the effected files, they > >just come back on the next sync. > >There is no problem on the ext3 file system. So how can I stop this from > >happening, and get a clean sync. Do I remove the effected files from the > >ext 3 fs, or is there another way to tell rsync to skip the files. How > > Why do that? So errors stop occuring and I can sync all of my music? > > >do I see what files are causing the trouble? I believe the file > >system is fat 32 on the mp3 player, this is the > >command I used to make it: > >sudo mkfs.vfat /dev/sdg1 > >Oh and here is my rsync command I use. > >rsync -avz /media/daniel-external/music/ /media/disk/music > > > > What about a simple "cp -vr"? It is a sync so only new files added get synced after the initial sync... cp fails as well btw from memory. > > > >If anyone could help me out with this I'd greatly appreciate it. > > Is this (the fs being set to RO) a repeatable process? Yes > > If so, and multiple mkfs.vfat and fsck.vfat commands don't solve the > problem, could some of the MP3 player's flash RAM be bad? Sure. The mp3 is about 3 years old and it's storage method is hdd (20 gb). It's an iriver h320... What are your thoughts? Is this likely the issue? How would you check if the mp3 is the problem? Thanks very much, Dan.
Attachment:
signature.asc
Description: Digital signature