Computing > General Computing

Share files and folders between W10 and Linux.

<< < (5/5)

As has been said, you can store things to share in FAT32 or NTFS based file systems if you construct the disc format / partitioning and file system format in compatible ways.
I'm not sure about details like DOS partitioning or GPT or whatever else may be possible that's a bit better than the most legacy DOS / Win2k compatible option.
Obviously don't turn on stuff like bitlocker and tread carefully if you want to use things like compression etc. in case there are compatibility issues between OSs.

That all being said there may be a simpler and possibly better option.  I get that you have a few local data drives attached to the particular computer and it sounds like you're
dual booting anyway.  Though I have to wonder what you're using for backups and file servers and so forth when you want to share and preserve data outside of that particular PC?

If you had a suitable file server or NAS or such you might just be able to put the data file systems to be shared on the NAS / server, then access them from both
platforms via either / both of CIFS / SAMBA or NFS for multi-platform accessibility and data sharing / centralization facilitation.

Having it shared from a server also may help data integrity since then you would have more choices like RAID backed storage whereas you'd have to be both careful and brave
to try to dual boot between LINUX and windoze and have a software based RAID as well as a file system shared between the two OSs in a fully compatible way.

Personally I'd also question the dual booting strategy.  You could possibly just run linux and virtualize windows under linux or run windows and use either WSL or a full VM to run your linux environment then you'd have simultaneous access to applications / tools / data that is unique to each environment as well as simplifying the data disc sharing between the two because
the VM layer should have simple options to share mounts / directories / files etc.

another consideration.
There has been a huge uptick in malware and hacker activity in general over the last decade.
When I got into IT work dealing with malware was an occasional thing.
In the last few years it has become a huge part of enterprise computing.
We once had our postal meter hacked! Which by the way was running Linux, so if anyone thinks Linux is so cool it doesn't get hacked...
I can reel off a bunch of funny anecdotes about hackers, malware etc.
But the point is that malware is on the minds of people who engineer these operating systems.
For this reason Windows is going to look sideways at any other operating system it finds on "their storage".
That is what a some remote Access Tools look like. Distros!
Microsoft knows that some people dual boot. But it's just not as robust about this as MACOS or Linux.
Then there is that god damned Windows 10 update thing.
Good luck having that continue to play nice with another operating system once you have them cooperating.
I've seen Win 10 automatic updates take down all kinds of normal software. And more than once just wreck a good system to the point we erased it and started over.


You also have the option to use VMware for virtual machines with Linus, in this case, will be a graphical drag and drop, ins any direction

I believe the best approach is single boot Linux, with VMware to run windows
(or Virtualbox for maker/hobbyist/home use).

Ofcourse, make sure your pc is Linux compatibel, specially the graphics card.
Do NOT use nvida cards! Use AMD with the default opensource drivers.
Do NOT install any closedsource videodrivers.

On Linux you can assign a directory which content will be shared with windows.
In windows this appears as a networkdrive. Files can be shared in both directions.

This is the most safe and reliable setup.

In the past I have used a Linux windows 7 dualboot setup using separate harddisks.
Windows was installed first on the first harddisk and Linux after that on the second.
The bootloader was Grub.
This worked reasonably apart from that you can't use both systems at the same time which is a pitty.
Then, after some years, microsoft started to release some updates that required to restart the pc,
continued to install some update, and restarted the pc again. Some of these updates didn't play well with
a dualboot with Linux (Grub). During the second phase of the installation of the update, windows reported
that it was not able to install the update and reverted it. It puzzled me but after some time I discovered
that, when I disconnected the second harddisk with Linux and instructed the bios to boot from the first disk,
the installation of these problematic updates went fine.
So, from that moment, every time when there were new updates, I risked to loose time caused by some
windows update that didn't play nice with Grub and dualboot Linux and I had to open the pc, disconnect the
sata cable to the second disk, change a bios setting, boot windows, perform the problematic update,
and do everything again in the reverse order.

So, after some more time I decided that enough was enough and I pulled out the windows disk,
installed virtualbox and windows on top of Linux.

I couldn't be more happier.

I don't know if these problems still exist with windows 10. I'm not going to try because over the years I
have lost all my trust in microsoft and even if they changed their nasty behaviour, I'll continue to avoid them
like the plague, just because of what they did in the past.
Fool me once, shame on you. Fool me twice, shame on me.

Speaking from painful personal experience I've been pretty poorly served by both nvidia and amd in terms
of linux drivers.  Even though amd has quasi-semi-eventually open sourced parts of their video driver / GPU related codes and hardware documents, as far as I know vast amounts of the driver and other GPU support code isn't open source.
And where there was open sourced information sometimes they took so long to release it that the current generation
cards were basically obsolete before anything but basic "yeah I can see the screen" support actually was available.
So with AMD cards one could either use the open source drivers / windowing support stuff and that would often be adequate
if one wanted to "just see the screen" and have very basic accelerated 2D/3D support.  But if one wanted anything better
than that like a more full set of accelerated 3D, good OpenCL / GPGPU support, GPU card / video settings management utilities that worked comprehensively, etc. you'd often be out of luck.
And you'd have to look at the open source stacks hardware compatibility lists to even see what features were supported for a given GPU model / architecture.  And since AMD changed architectures pretty much every generation, typically new cards were lagged behind in even basic support years.

Or you could use the AMD proprietary drivers / tools, but then they would only work with certain kernel versions, after
not very long of a time they'd often declare a product "end of support life" which basically meant that if you wanted to use a newer Xorg version or newer kernel version your final-available-version EOL'ed video drivers wouldn't work at all with the next
LTS version of your LINUX (e.g. Ubuntu LTS or such).  And because new cards would be slowish to support well you might
have the current LTS version of linux be 1 years old coincidentally when AMD released the new card generation, then forward to a year or so later by the time the support might be out for relatively stable use with that LTS, then if you're lucky you might be able to run the next LTS before AMD would stop supporting that card generation for kernel / Xorg so basically you'd be trapped on that LTS version or maybe that +1.

NVIDIA: No choice to reallty run the open source drivers unless ALL you want is "yeah I can see the screen, usually".
No likelihood of good open source acceleration, video card / screen management utilities, OpenCL, CUDA support, AIML support, etc.
But if you do run the NVIDIA drivers you get stuck with whatever kernel / Xorg versions they support which often won't be really recent ones, so you may end up running an outdated LINUX version just to have the GPU drivers work.
Then same issues as AMD  with "end of life" card driver support when the card itself may only be a couple/few years old and you can't even move up to the next LTS linux that comes out if it has much newer kernel / Xorg.

And Vulkan linux window environment support is a royal mess for NVIDIA; don't know about AMD.

I don't think either one is commendable until you can:

1: Run CUDA / OpenCL / AIML / GPU X / GPU Vulkan with good acceleration.
2: Run that with open source support.
3: Be able to run at least the next 2-3 LTS release versions of linux and have the thing work with the current kernel / X / Vulkan for those after purchasing any card model that is available new.
4: Have accelerated video codec / playback support that works well in LINUX and is open sourced.

That said, if you can live with NVIDIA's bad support of LINUX in their closed drivers, at least you tend to get more stuff that works moderately well from the NVIDIA drivers than the AMD drivers.  e.g. relatively up to date AIML / CUDA / OpenCL support and such as opposed to historically not so much so in AMD.  I hear AMD has been trying to improve some of that, we'll see how that goes later in this generation.

Currently though you can't even BUY a decent NVIDIA or AMD GPU unless you make a 6-month long quest for the holy grail out of shopping, so the choice is academic.

--- Quote from: Karel on June 13, 2021, 06:33:52 am ---I believe the best approach is single boot Linux, with VMware to run windows
(or Virtualbox for maker/hobbyist/home use).

Ofcourse, make sure your pc is Linux compatibel, specially the graphics card.
Do NOT use nvida cards! Use AMD with the default opensource drivers.
Do NOT install any closedsource videodrivers.

--- End quote ---


[0] Message Index

[*] Previous page

There was an error while thanking
Go to full version