Is there a cancel option? If there isn't then it is probably safest to leave it, although the worst that will happen if you forced it to stop, is it'll leave the filesystem in a worse state than before, but only if it is in the middle of making changes to the filesystem when you stop it

Not to mention that doing a surface scan will potentially reduce the life of the card depending on what such scan does.

no cancel button just the X so I guess I gota leave it let it run

But where's the fun in that?

well i see your point.

$ cat /proc/mounts
rootfs / rootfs rw 0 0
ubi0:rootfs / ubifs rw,bulk_read,no_chk_data_crc 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
tmpfs /tmp tmpfs rw,noatime,size=1024k 0 0
tmpfs /var/run tmpfs rw,nosuid,noatime,size=256k,mode=755 0 0
none /dev tmpfs rw,noatime,size=10240k,mode=755 0 0
devpts /dev/pts devpts rw,gid=5,mode=620 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev,noatime,size=65536k 0 0
/dev/mmcblk0p2 /home ext3 rw,noatime,errors=continue,commit=1,data=writeback 0 0
/dev/mmcblk0p2 /opt ext3 rw,noatime,errors=continue,commit=1,data=writeback 0 0
cgroup /syspart cgroup rw,freezer,memory,cpu 0 0
nodev /sys/kernel/debug debugfs rw 0 0
/dev/mmcblk0p2 /usr/lib/python2.5 ext3 rw,noatime,errors=continue,commit=1,data=writeback 0 0
/dev/mmcblk0p2 /usr/share/pyshared ext3 rw,noatime,errors=continue,commit=1,data=writeback 0 0
/dev/mmcblk0p2 /usr/lib/pyshared ext3 rw,noatime,errors=continue,commit=1,data=writeback 0 0
/dev/mmcblk0p2 /usr/share/python-support ext3 rw,noatime,errors=continue,commit=1,data=writeback 0 0
/dev/mmcblk0p2 /usr/lib/python-support ext3 rw,noatime,errors=continue,commit=1,data=writeback 0 0
/dev/mmcblk0p1 /home/user/MyDocs vfat ro,nosuid,nodev,noexec,noatime,nodiratime,uid=2999 9,fmask=0133,dmask=0000,allow_utime=0022,codepage= cp437,iocharset=iso8859-1,shortname=mixed,utf8,rodir,errors=remount-ro 0 0
/dev/mmcblk1p1 /media/mmc1 vfat rw,nosuid,nodev,noexec,noatime,nodiratime,uid=2999 9,fmask=0133,dmask=0000,allow_utime=0022,codepage= cp437,iocharset=iso8859-1,shortname=mixed,utf8,rodir,errors=remount-ro 0 0
~ $


Here you go

ive had a similar problem that was fixed by connecting to win7 pc via mass storage gave me an option of fix errors, after that was finished it was fixed

hey!



to see if it gives an errormessage that gives a hint to what is wrong.


plan to is either of(you choose!)

1. backup and reformat mmcblk0p1 and play back the backup afterwards. mount in: done.
2. unmount mmcblk0p1 and do a file system check on /this/ partition(mmcblk0p1). in this case i would also suggest a backup first if it is possibile(actually i never do that myself: where would be the risk and fun if i did )

but lets see first see what mount tells. if we learn something new from that.

and btw a tip: you have an external mmc(mounted to /media/mmc1). if i play around and do potential dangerous things, i do it on that external mmc. that way i don't interfere with maemo.

I looked at /dev/mmcblk0p1 and mmcblk0p1 is 0bytes large. Is this normal?

also there is a broken symlink called core...
hmmmm

Yes, it isn't a real file, just a pointer to a block device.

I've got that too, it points to a file in the /proc directory which is dynamically generated by the kernel. Maybe it is related to a change made in Titan's kernel (the power kernel). I wouldn't worry about it though.

So are you still unable to delete that directory? Maybe you should try doing the filesystem check on the N900 if Windows didn't fix anything (I promise it won't take as long as the Windows scan did). Have you tried deleting your problem folder when it is mounted on your Windows PC?