13.1 freezes while copying files

On 2014-06-03 18:56, ratzi wrote:

> But in the end dolphin should do the job. See a posting to follow.

Yes, it should.

But over the years, I got better results with ‘mc’ than with most GUI
file browsers. As it doesn’t have to bother with drawing nice graphics
on the screen, it is faster and simpler.

> Now MacOS 9 adds a file ‘FINDER.DAT’ and sometimes a folder ‘RESOURCE.FRK’
> in every folder of a USB pen drive, which itself is formated FAT32.
>
> I already made the following experience: making a backup to a windows volume of a USB pen drive -
> that by MacOS 9 has been ‘amended’ this way - results in that ‘scandisk’ of windows thinks that
> the volume has errors and has to be repaired!
> But if I manually delete all these 'FINDER.DAT’s and 'RESOURCE.FRK’s beforehand,
> scandisk is completely happy!

Oh? :-o

I found this note in a forum (2004): “Unlike windows, which relies on
the extension to determine what a file is, the Macintosh uses the
resource fork folder to tell it what is what. I believe finder.dat holds
window settings (what size the folder was viewed at, how the icons were
arranged, etc.)…”

(http://www.highdots.com/forums/macromedia-dreamweaver/what-finder-dat-files-85858.html)

And this other, even better (2002):

“To copy a macintosh file into MS-DOS disk and back without loosing
anything, the system creates in each folder two hidden items, a file
named “finder.dat” and a subfolder named “resource.frk”.”

“The data fork is stored in the normal folder, under the main name of
the file. The resource fork is stored in the resource folder under a
truncated name.”

(http://www.windowsbbs.com/legacy-windows/2480-what-finder-dat.html)

And the wikipedia has more:
http://en.wikipedia.org/wiki/Resource_fork

“The resource fork is a construct of the (classic) Mac OS operating
system used to store structured data in a file, alongside unstructured
data stored within the data fork. A resource fork stores information in
a specific form, containing details such as icon bitmaps, the shapes of
windows, definitions of menus and their contents, and application code
(machine code). For example, a word processing file might store its text
in the data fork, while storing any embedded images in the same file’s
resource fork. The resource fork is used mostly by executables, but
every file is able to have a resource fork.”

“Currently, OS X supports resource forks on Windows SMB shares by
creating a hidden file in the same directory with the data fork file,
with the characters “._” at the beginning of the file name. However,
this may be annoying for some users, especially because some Windows
power users always keep hidden files visible. Besides, Windows does not
treat those files correctly as the file itself is moved or removed. A
few resource fork files created by OS X on an SMB share can be disabled
by an Apple supported action.”

But nowhere can I find a reference explaining your problem, they should
be just files.

>> I know of a certain proprietary application that does a good job of
>> recovering files out of a bad ntfs partition, and it is not expensive,
>> if that’s what you want… (yes, I tried photorec first. Horrible).
>
> Thank you.
> Maybe I’ll contact you on that if everything here goes wrong.
>
> But usually I prefer to have a sufficient number of backup copies (which
> just decreased by one, see above),
> instead of relying on such tools:

Oh, indeed backups are the best thing to have, absolutely :slight_smile:

I know of that tool because I had to help a friend. The ntfs filesystem
was corrupted beyond repair, even by Windows. A certain metadata
structure on the disk had been destroyed (I don’t remember the name of
the structure). I tried several opensource tools, got nowhere (photorec
just recovered some multimedia files). The home page of photorec had
advice for this particular problem, and recommended two proprietary
tools for it… It was not expensive and it worked.

> I just bricked a USB pen drive using ‘testdisk’ included on the GParted
> live CD … it’s light went out for ever after telling ‘testdisk’ to
> write the changes to the partition table.

Wow! :frowning:

> This USB pen drive doesn’t even appear anymore in the list of dolphin of
> partitions/drives available.
> But it still hinders my BIOS from booting when it is plugged - kind of a
> zombie, now.

Plug it afterward booting, and look at the end of /var/log/messages just
after doing it.

If the stick is accessible, it could be reformatted.

> Code:
> --------------------
> myHost:~ # iotop -o
> If ‘iotop’ is not a typo you can use command-not-found to lookup the package that contains it, like this:
> cnf iotop
> myHost:~ #
> --------------------
>
>
> Probably that one needs a .rpm which I haven’t installed.

and “cnf iotop”, as the message says would tell you the exact package to
install, and the exact command line to use.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

Hi Carlos,

Yes, they are just files, and folders - otherwise I wouldn’t have been able to use openSUSE to delete them :wink:

For sure, the files ‘FINDER.DAT’ do not contain any windows settings!!

I can not tell you why scandisk of windows has less problems after all 'FINDER.DAT’s and RESOURCE.FRK’s are removed from the USB pen drive
(or copies of that),
I only can tell you that this is my (painful) practical experience.

On 2014-06-03 23:26, ratzi wrote:

>
> do you really want me to re-introduce the parameters in fstab that
> caused my problems?
>
> I could do, yes, and it would cause me more trouble, but what would be
> shown by that?

You can reinstate the fstab line, yes, and mount it. No need to copy any
file. Then umount, change back the line, and mount via desktop. The
output of “mount” both times would show what is different.

> I did the following, in order that you can see the effect:
> I mounted /windows/C (not mounted by default), before I called ‘mount’.
>
> The result of ‘mount’ then is
>
> Code:
> --------------------
> /dev/sda4 on /windows/D type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,blksize=4096)
> /dev/sda3 on /windows/C type fuseblk (rw,nosuid,nodev,noexec,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
> --------------------
>
>
> The differences between the settings for /windows/C and /windows/D
> (beforehand, the parameters for these 2 partitions in fstab were the same)
> may give you the clue that you want.

Let’s see:


>   /dev/sda4 on /windows/D type fuseblk (rw,nosuid,nodev,·······relatime,user_id=0,group_id=0,····················allow_other,blksize=4096)
>   /dev/sda3 on /windows/C type fuseblk (rw,nosuid,nodev,noexec,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)

None of those match the fstab that gives you problems, the
“user,noauto,users,gid=users,fmask=133,dmask=022” one. The “gid=users”
option would translate above as “group_id=100”. And the desktop would do
the mount under “/var/run/media/…”

For testing this you do not need to copy any file nor run risks. Just
mount, get the output of the command, umount. Once with the problematic
fstab line, then another time with the desktop.

> robin_listas;2647284 Wrote:
>> I’m not saying that is your case, but it is a possibility; running
>> “iotop -o” in a terminal could tell us that immediately. Or course, you
>> have to install it. Package iotop, default repos.
>
> Look, I don’t like to return to the state again, in which my system
> freezes during large copys.
> If all of my data has been copied and checked (!!), then I may make that
> test.
> Please don’t ask me now, because I may risk to loose my personal data
> (like photographs of my kids and more).

Oh, ok. :slight_smile:

Of course, by all means, restore all your data safely, that’s the most
important thing!

Absolutely, you must not risk your data.

Once data is safe, if you can test again, it would be useful, for
others, if we can find the cause.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

You want more?

Never, ever, try to rename a file or folder on your USB stick while accessing it under MacOS 9.
Otherwise the file system of the USB stick will be rendered unusable.

On 2014-06-04 00:06, ratzi wrote:

>
> Yes, they are just files, and folders - otherwise I couldn’t have used
> openSUSE to delete them :wink:

Yes, of course. But Windows should not have been bothered with them,
either, if they are just files - unless there is something fizzy with
them, or Windows tries to get some metadata out of them first.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

However, we were talking about openSUSE.

Did you find the information that you wanted in the above output of ‘mount’ ?

I missed your post http://forums.opensuse.org/showthread.php/498487-13-1-freezes-while-copying-files?p=2647306#post2647306

OK, I will do it for you.

Carlos,

without the parameters “user,noauto,users,gid=users,fmask=133,dmask=022” for /windows/D in fstab
the output of mount is:

devtmpfs on /dev type devtmpfs (rw,relatime,size=3932868k,nr_inodes=983217,mode=755)
tmpfs on /dev/shm type tmpfs (rw,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
/dev/sda7 on / type reiserfs (rw,relatime)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=30,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
mqueue on /dev/mqueue type mqueue (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
tmpfs on /var/run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
tmpfs on /var/lock type tmpfs (rw,nosuid,nodev,relatime,mode=755)
/dev/sda4 on /windows/D type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,blksize=4096)
/dev/sda9 on /home type reiserfs (rw,relatime)
/dev/sdb1 on /run/media/alltag/HP v165w type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
/dev/sdb1 on /var/run/media/alltag/HP v165w type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro)
/dev/sda3 on /windows/C type fuseblk (rw,nosuid,nodev,noexec,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)

With the parameters “user,noauto,users,gid=users,fmask=133,dmask=022” included for /windows/D (i.e. the parameters that didn’t work for me)
the output of mount is:

devtmpfs on /dev type devtmpfs (rw,relatime,size=3932868k,nr_inodes=983217,mode=755)
tmpfs on /dev/shm type tmpfs (rw,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
/dev/sda7 on / type reiserfs (rw,relatime)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=29,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
mqueue on /dev/mqueue type mqueue (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
tmpfs on /var/lock type tmpfs (rw,nosuid,nodev,relatime,mode=755)
tmpfs on /var/run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
/dev/sda9 on /home type reiserfs (rw,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
/dev/sda4 on /windows/D type fuseblk (rw,nosuid,nodev,noexec,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
/dev/sda3 on /windows/C type fuseblk (rw,nosuid,nodev,noexec,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
/dev/sdd1 on /run/media/alltag/HP v165w type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
/dev/sdd1 on /var/run/media/alltag/HP v165w type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro)

You’re right, many of the parameters given in fstab don’t show up in the output of ‘mount’.

Mike

On 2014-06-04 02:16, ratzi wrote:
>
> Carlos,
>
> without the parameters “user,noauto,users,gid=users,fmask=133,dmask=022”
> for /windows/D in fstab
> the output of mount is:
>
>
> Code:
> --------------------
> /dev/sda4 on /windows/D type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,blksize=4096)
> /dev/sda9 on /home type reiserfs (rw,relatime)
> /dev/sdb1 on /run/media/alltag/HP v165w type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
> /dev/sdb1 on /var/run/media/alltag/HP v165w type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro)
> /dev/sda3 on /windows/C type fuseblk (rw,nosuid,nodev,noexec,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
> --------------------
>
>
> With the parameters “user,noauto,users,gid=users,fmask=133,dmask=022”
> included for /windows/D (i.e. the parameters that didn’t work for me)
> the output of mount is:
>
>
> Code:
> --------------------
> /dev/sda9 on /home type reiserfs (rw,relatime)
> /dev/sda4 on /windows/D type fuseblk (rw,nosuid,nodev,noexec,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
> /dev/sda3 on /windows/C type fuseblk (rw,nosuid,nodev,noexec,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
> /dev/sdd1 on /run/media/alltag/HP v165w type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
> /dev/sdd1 on /var/run/media/alltag/HP v165w type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro)
> --------------------

Thanks! :slight_smile:

> You’re right, many of the parameters given in fstab don’t show up in the
> output of ‘mount’.

Let’s compare:


>   /dev/sda4 on /windows/D type fuseblk (rw,nosuid,nodev,·······relatime,user_id=0,group_id=0,····················allow_other,blksize=4096)
>   /dev/sda4 on /windows/D type fuseblk (rw,nosuid,nodev,noexec,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)

And the second one is the one that gives problems…

Did you mount it via command line, or via desktop, or…? How exactly do
you mount it?

It looks like it was installed by the desktop, which does not parse
fstab lines entirely. That would explain why some of the options were
ignored. I will have to do some testing of my own to compare things…

In any case, neither of both mounts have any thing significantly
different that could cause problems, that I can see.

Although… fuseblk hides from us the actual ntfs driver used. Maybe
something else is hidden?

The only explanation I can think of, is that something else is accessing
the disk at the same time as you do (an indexer?). Maybe the different
permission set allow that whatever to access in one case and not the other.

The problematic indexer I was thinking of came with the latest KDE
version from the repos, I understand :-?

Sigh… I don’t know.

Maybe iotop would show what it is, maybe not, but you can not risk your
data, so that’s out. Unless you can try again when data is secured.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

That’s right.

In all cases I mounted the /windows/D partition using dolphin.
I like the command line whenever it’s useful.
But I avoid it whenever I can do things with a mouse click, instead of typing commands and parameters.

Options like ‘fmask=133,dmask=022’ that were given in fstab (in the case of freezing)
obviously don’t show up in the output of ‘mount’.

I wrote that I disabled desktop search.

Desktop search was annoying, because every external hard disk that was plugged,
was busy for at least 15 mins, before I could use it for my tasks.

So I disabled desktop search.

I have to correct this: in the setup that worked, using the partitioner of YaST,
I unchecked the fstab option ‘Do not mount at system start-up’,
so in that case this partition was mounted right from the start-up.

On 2014-06-04 04:06, ratzi wrote:

> robin_listas;2647327 Wrote:

> In all cases I mounted the /windows/D partition using dolphin.
> I like the command line whenever it’s useful.
> But I avoid it whenever I can do things with a mouse click, instead of
> typing commands and parameters.

Mounting by CLI would absolutely comply with fstab options; Dolphin
(which calls something else, forgot the name), does not.

>

> robin_listas;2647327 Wrote:
>> In any case, neither of both mounts have any thing significantly
>> different that could cause problems, that I can see.
>>
>> Although… fuseblk hides from us the actual ntfs driver used. Maybe
>> something else is hidden?
>
> Options like ‘fmask=133,dmask=022’ that were given in fstab (in the case
> of freezing) obviously don’t show up in the output of ‘mount’.

Yes, but others like the filesystem type do not show, only “fuseblk”.

> robin_listas;2647327 Wrote:
>> The only explanation I can think of, is that something else is accessing
>> the disk at the same time as you do (an indexer?). Maybe the different
>> permission set allow that whatever to access in one case and not the
>> other.
>>
>> The problematic indexer I was thinking of came with the latest KDE
>> version from the repos, I understand :-?
>
> I wrote that I disabled desktop search.

I know. But there is now a new incantation of it. Different name and
packages. I can not specify, I do not use the full KDE desktop. I should
have notes on it somewhere.

> Desktop search was annoying, because every external hard disk that was
> plugged,
> was busy for at least 15 mins, before I could use it for my tasks.
>
> So I disabled desktop search.

Yes, understandable. But I have the gut feeling that it is involved here.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

I have the same problem with openSUSE 13.2 64 Bit. Copy large files (about 1 GB) via dolphin to USB stick makes desktop (KDE 4) unresponsive. See also https://forums.opensuse.org/showthread.php/472088-OpenSuse-12-1-freezes-while-copying-data

On 2015-07-17 18:46, codeminister wrote:
>
> I have the same problem with openSUSE 13.2 64 Bit. Copy large files
> (about 1 GB) via dolphin to USB stick makes desktop (KDE 4)
> unresponsive. See also http://tinyurl.com/mvhq5z5

I learned since that of an explanation. I don’t know if it is written
somewhere in these two threads; at worst I’ll waste some of my time :slight_smile:

The issue is that any file that is read or written is cached in RAM by
the kernel. If you write a big file (or many smaller files) to a slow
writing device, such as an USB stick, that chunk of memory is occupied
for all that time, being unavailable for any other process that may need
memory, and thus slowing the responsiveness of the entire system.

The trick is to use a copy program that knows how to write directly
without caching data. I only know how to do this with “dd” for a single
file; for a bunch of them, you would have to script it. See man dd,
option “direct”; possibly “nocache” might work, too (unverified).


Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))