Bug 25922 - Errors when moving (not copying) files to NTFS between different hard drives
Summary: Errors when moving (not copying) files to NTFS between different hard drives
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia tools maintainers
QA Contact:
URL: https://bugs.kde.org/show_bug.cgi?id=...
Whiteboard: MGA8TOO
Keywords:
: 27327 31524 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-12-21 23:35 CET by MAG Linares Andalucía
Modified: 2023-11-06 19:48 CET (History)
5 users (show)

See Also:
Source RPM: diskdrake
CVE:
Status comment:


Attachments

Description MAG Linares Andalucía 2019-12-21 23:35:15 CET
Description of problem:
When I try to move files from the Linux ext4 partition to the "fuseblk" partition, I always receive two errors:

- Access denied to {destination}. Retry or cancel
- The file or folder {source} does not exist. Retry or cancel

Finally, to move the files well, I have to copy / paste / delete, with the consequent loss of time.

Version-Release number of selected component (if applicable): 
19.04.0



How reproducible:
Moving files to a NTFS partition.


Steps to Reproduce:
1. Open destination folder
2. Select a lot of files
3. Try to move to destination folder
MAG Linares Andalucía 2019-12-21 23:37:32 CET

Whiteboard: (none) => dolphin
Keywords: (none) => 7final

Comment 1 Florian Hubold 2019-12-22 14:36:36 CET
For reference, this is the upstream bug for this issue: https://bugs.kde.org/show_bug.cgi?id=378946 ( which is marked as a duplicate and being tracked via https://bugs.kde.org/show_bug.cgi?id=364039 )

There seems to be a fix for https://bugs.kde.org/show_bug.cgi?id=368287 but I don't see any confirmation that it fixes https://bugs.kde.org/show_bug.cgi?id=364039 too.

Workaround seems to be to add uid and gid to mount options.

Keywords: 7final => (none)
CC: (none) => doktor5000
Whiteboard: dolphin => (none)
Source RPM: filesystem-2.1.9-30.mga7.src.rpm => dolphin-19.04.0-1.mga7.src.rpm
URL: https://forums.mageia.org/en/download/file.php?id=1896 => https://forums.mageia.org/en/viewtopic.php?f=7&t=13225

Comment 2 Lewis Smith 2019-12-22 15:09:13 CET
@Linares Andalucía
Thank you for reporting this.
And thank you Florian for all the pointers. There are very many duplicate bugs there.
I have changed the URL reference from:
 https://forums.mageia.org/en/viewtopic.php?f=7&t=13225
to the upstream bug; I think this is what is required for such bugs.

(In reply to MAG Linares Andalucía from comment #0)
> Finally, to move the files well, I have to copy / paste / delete, with the
> consequent loss of time.
The loss of time must be very small - just that for deletion of the source.
Note the workaround in comment 1.
Have you tried a different file manager from Dolphin?

Summary: Errors when moving (not copying) files between different hard drives. => Errors when moving (not copying) files to NTFS between different hard drives
Assignee: bugsquad => kde
Keywords: (none) => UPSTREAM
URL: https://forums.mageia.org/en/viewtopic.php?f=7&t=13225 => https://bugs.kde.org/show_bug.cgi?id=364039

Comment 3 MAG Linares Andalucía 2019-12-22 23:29:53 CET
Yes I tried, specifically with Konqueror, and it happens exactly the same.
Lewis Smith 2020-09-28 09:19:32 CEST

Whiteboard: (none) => MGA7TOO
Version: 7 => Cauldron

Comment 4 Lewis Smith 2020-09-28 09:27:51 CEST
*** Bug 27327 has been marked as a duplicate of this bug. ***

CC: (none) => kourki

Comment 5 Lewis Smith 2020-09-28 09:32:10 CEST
(In reply to MAG Linares Andalucía from comment #3)
> Yes I tried, specifically with Konqueror, and it happens exactly the same.
Another Bug 7985 suggests https://bugs.mageia.org/show_bug.cgi?id=7985#c22 :
"The problem doesn't appear in both case when I try to explore the content of these HDD with PCManFM-QT PCManFM or Thunar".
Worth trying.

CC: (none) => lewyssmith

Comment 6 Ami age 2020-09-28 19:37:34 CEST
I indicated in the bug https://bugs.mageia.org/show_bug.cgi?id=27327

by deleting directly in the umask = 000 fstab file, the bug is solved, cutting and pasting it with an ntfs partition works.

but I don't know if this has other consequences

en français :
J'ai indiqué dans le bug  https://bugs.mageia.org/show_bug.cgi?id=27327 

en supprimant directement dans le fichier fstab umask=000, le bug est résolu, le couper coller avec une partition ntfs fonctionne.

mais je ne sais pas si celà entraine d'autres conséquences.
Comment 7 Dave Hodgins 2020-09-28 20:06:14 CEST
I believe this may be intentional. Both linux and windows support having
multiple users. Deciding which linux users should have access to the ntfs
files is up to the system admin, so by default only root should have access.

While most of the users of Mageia are their own system administrators, that
is not true for all Mageia installations.

CC: (none) => davidwhodgins

Comment 8 Ami age 2020-09-28 21:57:43 CEST
293/5000
This explanation does not make sense because in this case, one should not be able to delete a file on another ntfs partition.

And yet, since the cut paste is hs, I copy, paste, and delete the original file without difficulty.

and cut it paste with thunar allows it.
------------
en français
Cette explication n'est pas logique car dans ce cas, on ne devrait pas pouvoir suprimmer un fichier sur une autre partition ntfs.

Et pourtant, vu que le couper coller est hs, je copie, je colle, et je supprime sans difficulter le fichier d'origine.

et le couper coller avec thunar le permet.
Comment 9 Marja Van Waes 2023-02-08 16:09:47 CET
*** Bug 31524 has been marked as a duplicate of this bug. ***
Comment 10 papoteur 2023-02-09 09:09:33 CET
(In reply to Dave Hodgins from comment #7)
> I believe this may be intentional. Both linux and windows support having
> multiple users. Deciding which linux users should have access to the ntfs
> files is up to the system admin, so by default only root should have access.
> 
> While most of the users of Mageia are their own system administrators, that
> is not true for all Mageia installations.

I don't think this is intentional. A user can copy the file in the destination filesystem, then delete the source. I don't understand why the both effects in one operation (cut) would be considered more dangerous.
This is a bug.

CC: (none) => yves.brungard_mageia

Comment 11 papoteur 2023-02-09 09:15:12 CET
And Ami_Age pointed to a solution where the settings in /etc/fstab are adjusted
Thus, this is probably a question for diskdrake.

Source RPM: dolphin-19.04.0-1.mga7.src.rpm => diskdrake
Whiteboard: MGA7TOO => MGA8TOO
Assignee: kde => mageiatools
Keywords: UPSTREAM => (none)

Comment 12 papoteur 2023-02-09 09:15:48 CET
See https://bugs.mageia.org/show_bug.cgi?id=27327#c6
Comment 13 Ami age 2023-09-09 17:19:44 CEST
Good morning,
With Mageia 9 64bits KDE PLASMA freshly installed, it works, there are no more bugs.
To see over time.
----------------------------------------------
Bonjour,
Avec Mageia 9 64bits KDE PLASMA fraichement installée, celà fonctionne, il n'y a plus de bug.
A voir dans la durée.
Comment 14 Ami age 2023-11-06 19:48:42 CET
Good morning,

(Error on my part, the partitions were not in the fstab and in fact I typed the root password.)

The bug is still present

------------------------------------------
Good morning,

(Error on my part, the partitions were not in the fstab and in fact I typed the root password.)

The bug is still present

Note You need to log in before you can comment on or make changes to this bug.