From within linux mint

Linux Mint Forums

Linux Mint 19.1 — File Transfer Between Ext4 & NTFS Partitions

Forum rules
There are no such things as «stupid» questions. However if you think your question is a bit stupid, then this is the right place for you to post it. Please stick to easy to-the-point questions that you feel people can answer fast. For long and complicated questions prefer the other forums within the support section.
Before you post please read how to get help. Topics in this forum are automatically closed 6 months after creation.

Linux Mint 19.1 — File Transfer Between Ext4 & NTFS Partitions

Post by Archi_21 » Wed Apr 10, 2019 8:46 am

Hi, I am new to Linux though have worked with computers and Dos for over 40 years.
I was fed-up with the inane updates and bloatware that the Windows 10 release forced on to Users and decided to take the plunge and move across to Linux Mint amongst the many Ubuntu and Linus software applications available. I was not prepared to upgrade my desktops to Win10 from Win7 with Microsoft support ceasing for Win7 in Feb 2020. My goal was to transfer existing MS-Word files, pics and movies across to Linux as time allowed. I had read that files transfers were tolerated in Linux Mint between NTFS and Ext4 partitions native to Mint. I therefore transferred files to Mint via the «copy», «move» processes and deleted a certain many of non-required files. Care was taken in this process to mount and unmount the NTFS drives viewable in the native file manager to Mint 19.1 (Nemo?).

However, on booting back to Windows I noted those files accessed on the NTFS logical drives within Mint were either missing directories or certain disks were non-accessible. Worse still, it was apparent those non-accessible were corrupted with the «dirty» marker flagged such that when re-booting into Windows the chkdsk /f function was served on those disks with all manner of orphan entries found and files and directories recovered. The disks were then accessible however not all directories and files were recovered. I learnt long ago to take backups of critical data and had to resort to using back copiesto restore entire disk images to retrieve a full set of files.

I understand there are drivers within Mint 19.1 that are meant to make the transfers above possible. However, my experience suggests there are significant incompatibility issues between Mint 19.1 Ext4 and Windows generated NTFS partitions. This raises the question of how best to achieve transfers between the two Systems since there are still critical applications in Windows I need to continue to use as a business user.

After the shock, horror of resurrecting my data set back to my respective 6 disks [no light order], I have now formatted an external Seagate drive in FAT32 format since I understand this can serve as a happy medium for transferring data between the two Systems without corruption. Is this assumption correct?
What other factors might I have to consider moving data across to this disk within Win7 for opening in Linux Mint 19.1 and vice versa?

I would be very grateful to knowledgeable Users providing assistance on this matter, since I can’t go down the path of resurrecting disks again! I must say I am impressed with the integrity of the dataset in Mint and its overall operation in general, but for this compatibility issue of transferring data between Win7 and Mint.
I have searched the forum but there does not appear to be one definitive answer with best workaround for this issue.

I have not mentioned also the fact that I am now limited to the transfer of 4Gb chunks of data to my nominated Seagate Transfer disk formatted with a FAT32 partition. With a high number of Win7 Users looking to transition to other systems in 2019 I would have thought Mint 19.1 would have had this compatibility issue down to pat.
I am not sure for New Users why there is not more guidance offered with this matter, since it must surely be common enough, I mean data migration between systems. Happy for those with experience in Linux code to offer suggestions, workarounds .
My Goal: To implement a reliable system of file transfer between both systems as a must.

Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 1 time in total.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.

Flemur Level 20
Posts: 10097 Joined: Mon Aug 20, 2012 9:41 pm Location: Potemkin Village

Re: Linux Mint 19.1 — File Transfer Between Ext4 & NTFS Partitions

Post by Flemur » Wed Apr 10, 2019 10:28 am

Archi_21 wrote: ⤴ Wed Apr 10, 2019 8:46 am I therefore transferred files to Mint via the «copy», «move» processes and deleted a certain many of non-required files. Care was taken in this process to mount and unmount the NTFS drives viewable in the native file manager to Mint 19.1 (Nemo?).

You copied some files and moved (=remove the original) others — ? The file manager depends on your desktop.

However, on booting back to Windows I noted those files accessed on the NTFS logical drives within Mint were either missing directories or certain disks were non-accessible.

I’ve never had about transferring from/to ntfs partitions.

«files were missing directories» = ??

You might want to read the «How to get help» post and supply more information about your system:
http://forums.linuxmint.com/viewtopic.php?f=17&t=83444

Please edit your original post title to include [SOLVED] if/when it is solved!
Your data and OS are backed up. right?

Re: Linux Mint 19.1 — File Transfer Between Ext4 & NTFS Partitions

Post by Archi_21 » Wed Apr 10, 2019 11:10 am

Hi Flemur,
I am running Linux Mint 19.1 on a separate SSD to Win7 on another SSD. Both are 64 bit versions of those operating systems.
My reference to moving and copying files from Windows NTFS partitions within Linux Mint, refers to transferring data (non-system files) from logical NTFS drives with datasets originally mounted within Windows. My transfers do not relate to the Windows 7 or Linux Operating System on SSD discs which are separate to my data disks.

Essentially for moving, copying data across from data discs created in Windows to the appropriate Linux directories — Docs, Pictures, Videos & etc. on re-entering Windows the discs accessed for the populating of Linux Mint were corrupted and/or missing. Interestingly, the data directories missing were the very ones accessed in Mint.

In short, when using the Nemo File Manager in Mint Cinnamon to copy, move or delete files on Windows NTFS partitions, it appears to corrupt them.

I am not able to confirm whether this corruption is a product of Nemo File Manager or the Drivers that are meant to make such file transfers between Ext4 and NTFS partitions possible. However, it was a very unpleasant experience having 3 x 1.2Tb data disks corrupted in this fashion. Lets say it took some shine of my new introduction to Linux Mint. I have read on this Forum of others having corruption issues in my instance.

I need to know how reliable transfers between Ext4 and NTFS partitions are meant to be from those in Development of Linux Mint and how I can avoid such issues arising when populating data across to Linux Mint 19.1. That is, solutions that can avoid any corruption re-occuring of my nature.

By the way, I am using an AMD computer with the below architecture. Fortunately, I rarely experience corruption issues and this has only occurred with this migration of data across to Linux Mint directories. Recommendations and suggestions to my file transfer issues are most welcome.

System: Host: tim-To-be-filled-by-O-E-M Kernel: 4.15.0-47-generic x86_64 bits: 64 compiler: gcc v: 7.3.0 Desktop: Cinnamon 4.0.10 wm: muffin dm: LightDM Distro: Linux Mint 19.1 Tessa base: Ubuntu 18.04 bionic Machine: Type: Desktop System: Gigabyte product: N/A v: N/A serial: Chassis: type: 3 serial: Mobo: Gigabyte model: 990FXA-UD3 serial: BIOS: American Megatrends v: F2 date: 07/15/2013 Battery: Device-1: hidpp_battery_0 model: Logitech M510 serial: charge: 55% status: Discharging CPU: Topology: 6-Core model: AMD FX-6300 bits: 64 type: MCP arch: Bulldozer L2 cache: 2048 KiB flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 42193 Speed: 1524 MHz min/max: 1400/3500 MHz Core speeds (MHz): 1: 1419 2: 1435 3: 1425 4: 1485 5: 1406 6: 1405 Graphics: Device-1: AMD Juniper PRO [Radeon HD 5750] vendor: ASUSTeK driver: radeon v: kernel bus ID: 01:00.0 chip ID: 1002:68be Display: x11 server: X.Org 1.19.6 driver: ati,radeon unloaded: fbdev,modesetting,vesa resolution: 1680x1050~60Hz OpenGL: renderer: AMD JUNIPER (DRM 2.50.0 / 4.15.0-47-generic LLVM 7.0.0) v: 3.3 Mesa 18.2.8 compat-v: 3.1 direct render: Yes Audio: Device-1: AMD SBx00 Azalia vendor: Gigabyte driver: snd_hda_intel v: kernel bus ID: 00:14.2 chip ID: 1002:4383 Device-2: AMD Juniper HDMI Audio [Radeon HD 5700 Series] vendor: ASUSTeK driver: snd_hda_intel v: kernel bus ID: 01:00.1 chip ID: 1002:aa58 Sound Server: ALSA v: k4.15.0-47-generic Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet vendor: Gigabyte driver: r8169 v: 2.3LK-NAPI port: b000 bus ID: 05:00.0 chip ID: 10ec:8168 IF: enp5s0 state: up speed: 1000 Mbps duplex: full mac: Drives: Local Storage: total: 5.01 TiB used: 108.38 GiB (2.1%) ID-1: /dev/sda type: USB vendor: Seagate model: Backup+ SL size: 931.51 GiB serial: ID-2: /dev/sdb vendor: Western Digital model: WD10EADS-00M2B0 size: 931.51 GiB speed: serial: ID-3: /dev/sdc vendor: Seagate model: ST2000DM001-1CH164 size: 1.82 TiB speed: serial: ID-4: /dev/sdd vendor: Crucial model: CT512MX100SSD1 size: 476.94 GiB speed: 6.0 Gb/s serial: ID-5: /dev/sde vendor: Samsung model: SSD 860 EVO 500GB size: 465.76 GiB speed: 6.0 Gb/s serial: ID-6: /dev/sdf vendor: Hitachi model: HDS721050CLA362 size: 465.76 GiB speed: 3.0 Gb/s serial: Partition: ID-1: / size: 136.50 GiB used: 9.85 GiB (7.2%) fs: ext4 dev: /dev/sde1 ID-2: /home size: 301.61 GiB used: 83.78 GiB (27.8%) fs: ext4 dev: /dev/sde5 ID-3: swap-1 size: 18.62 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sde6 Sensors: System Temperatures: cpu: 18.1 C mobo: N/A gpu: radeon temp: 34 C Fan Speeds (RPM): N/A Repos: No active apt repos in: /etc/apt/sources.list Active apt repos in: /etc/apt/sources.list.d/official-package-repositories.list 1: deb http: //mirror.internode.on.net/pub/linuxmint-packages tessa main upstream import backport 2: deb http: //mirror.internode.on.net/pub/ubuntu/ubuntu bionic main restricted universe multiverse 3: deb http: //mirror.internode.on.net/pub/ubuntu/ubuntu bionic-updates main restricted universe multiverse 4: deb http: //mirror.internode.on.net/pub/ubuntu/ubuntu bionic-backports main restricted universe multiverse 5: deb http: //security.ubuntu.com/ubuntu/ bionic-security main restricted universe multiverse 6: deb http: //archive.canonical.com/ubuntu/ bionic partner Info: Processes: 220 Uptime: 1h 12m Memory: 7.82 GiB used: 2.59 GiB (33.2%) Init: systemd v: 237 runlevel: 5 Compilers: gcc: 7.3.0 alt: 7 Client: Unknown python3.6 client inxi: 3.0.27

Источник

Linux Mint Forums

install mint from within debian on unused diskspace

Forum rules
Before you post please read how to get help. Topics in this forum are automatically closed 6 months after creation.

install mint from within debian on unused diskspace

Post by brunaux » Fri Jul 27, 2012 2:47 pm

installation via cd:
I am trying to install linux mint 32 bit on an dell xps gen4 with a pentium4 32 bit processor .
it is too complicated for me to repackage the mint .iso to fit on a cd, but i could install debian via cd.

why i cannot use usb-boot:
the bios allows me to select usb boot but gives me an error which says that no bootable information can be found on the device
(i installed the checksummed proved mint .iso with unetbootin on various fat32 usb sticks . same result) .

i want to install linux mint from within debian os:
i have 2 hard disks and only one is partioned and in use with debian linux.
i thought i could somehow install mint to the unpartioned second hard drive from debian
finally acess mint and
then delete debian from within mint.

since i am a linux newbie i do not know what i have to do & which programs/tools to use.
i have gparted and unetbootin installed but i dunno what these tools can do for me .

Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 1 time in total.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.

Источник