On 11/18/17 13:41, Robin Laing wrote:
On 17/11/17 18:50, Ed Greshko wrote:
> On 11/18/17 09:16, Robin Laing wrote:
>> Just updated my F26 and went to copy some files to a stick for transfer. If I
try
>> to copy a file either with drag and drop or using Konsole and cp, the system
will
>> not copy the full file and will just freeze. I tried different sticks on the
>> system with no luck.
>>
>> I have tested with the same results on two different computers with different
>> sticks.
>>
>> It looks like I can copy small files but large files won't work. Even if I
try
>> copy files using sudo, it still does the same thing, using 3 or 4 processors to
>> 100% and the copy process hangs.
>>
>> I can mount the stick manually using sudo and copy files with no issue.
>>
>> Mount differences are:
>>
>>
>> This is what mount shows when I use the KDE desktop
>> /dev/sdc1 on /run/media/user/MyStick type vfat
>>
(rw,nosuid,nodev,relatime,uid=1100,gid=1100,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
>>
>>
>>
>> Mounting by sudo
>> /dev/sdc1 on /mnt/temp type vfat
>>
(rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
>>
>>
>> ps shows that the process is waiting for the drive with a D+ in the status. It
>> will do this for an hour if I leave it.
>>
>> I don't know where to start looking to report a bug to provide more details
for the
>> bug report.
>
>
> First, can you define "large"? I just transferred a 1GB file to mine
without
> trouble.
>
> When I plug in a USB drive and select "Open with File Manager" mount
shows...
>
> /dev/sdg1 on /run/media/egreshko/0E3723CF5E376877 type fuseblk
>
(rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)
>
>
> I think the differences may be due to my formatting the drive partition as ntfs.
Is
> there a chance you could use that instead of vfat?
>
NTFS is not an option. I don't know how many sticks you purchase that are already
formatted with NTFS and work on old and new windows. How many cameras do you know
that work with NTFS cards. I have to test some cards later when time permits.
Ahh, OK. I suppose it would have been sufficient to just say you can't use NTFS for
your case.
I am talking 400MB and above with my few tests. Same sticks when manually mounted
work okay.
OK. I found an old, cheap, USB stick that had nothing of value on it and it is
already formatted as vfat. Inserting it gives me
/dev/sdg1 on /run/media/egreshko/EB65-B61D type vfat
(rw,nosuid,nodev,relatime,uid=1029,gid=65539,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
I copied, via D&D in Dolphin, a 702MB mp4 file without difficulty. Forgot to check
my watch to see how long it took so I ran it again with time and this was the
result. The source file is on an NFS mounted partition so that may have affected the
speed. As I said, it is an old stick of unknown manufacture and doesn't have any
speed markings on it.
real 5m24.971s
user 0m0.003s
sys 0m1.713s
I wonder why the system shows that it is waiting for the drive which points me to a
communication issue between the USB sub system and KDE.
Sorry, I don't know. But if the transfer also fails to complete using "cp"
from the
command line it sounds not related to KDE but more kernelish.
I still want to know what sub-systems I need to watch to find out how to report
this. I have a bunch of work to do and if this is a continuing issue, it will cost
me in lost productivity.
Funny thing happened when I tried to transfer a file with File Manager. ls -l
showed the whole file transferred in less than 1 sec, even though it was a 700MB
file. Even the status graph was full before I could open the widget. Then the
hang. Full file was never transferred.
To me this is a critical bug.
I'm sure it is. Unfortunately I've been unable to duplicate and am therefore of
little help.
--
Fedora Users List - The place to go to speculate endlessly