Question as to whether Ubuntu or UbuntuMATE is 32 bit

[Robert Heller]

At Sun, 2 Sep 2018 11:00:33 -0700 "Ubuntu user technical support,  not for general discussions" <ubuntu-users at lists.ubuntu.com> wrote:

> 
> On Sat,  1 Sep 2018 20:25:05 -0400 (EDT)
> Robert Heller <heller at deepsoft.com> wrote:
> 
> > At Sun, 2 Sep 2018 05:58:57 +0800 "Ubuntu user technical support,
> > not for general discussions" <ubuntu-users at lists.ubuntu.com> wrote:
> > 
> > > 
> > > On 02/09/2018, Tony Arnold <tony.arnold at manchester.ac.uk> wrote:  
> > > > Bret,
> > > >
> > > > On Sun, 2018-09-02 at 05:04 +0800, Bret Busby wrote:
> > > >
> > > > On Sun, 2 Sep 2018, Bret Busby wrote:
> > > >
> > > >
> > > >
> > > > I have read, regarding RISC OS, that
> > > >
> > > >
> > > > "
> > > >
> > > > The file system abstraction layer API uses 32-bit file offsets,
> > > > making
> > > >
> > > > the largest single file 4 GiB (minus 1 byte) long.
> > > >
> > > > "
> > > >
> > > >
> > > > - https://en.wikipedia.org/wiki/RISC_OS
> > > >
> > > >
> > > > Now, that makes me wonder whether Ubuntu Linux, or, UbuntuMATE
> > > > Linux,
> > > >
> > > > is limited to 32 bit.
> > > >
> > > > I think the file size limits depends on the files system in use
> > > > as well as the OS.
> > > >
> > > >
> > > > The reason that this has arisen, is that I have a 4.5GB file that
> > > > I
> > > >
> > > > can not move - I have tried to move (using cut and paste) the
> > > > file,
> > > >
> > > > using both caja and PCManFM, and, with both, I get the problem
> > > > that
> > > >
> > > > the file is "too large to be spliced", and, a filesize limit of
> > > > 4GB
> > > >
> > > > apparently applies
> > > >
> > > >
> > > > So, is Ubuntu Linux, or, UbuntuMATE Linux, is limited to 32 bit,
> > > > or,
> > > >
> > > > are the file managers limited to 32 bit operations?
> > > >
> > > > What is the files system to which you are copying the file? And
> > > > what is the file system where the source file resides?
> > > >
> > > > ext4 support up to 16TB sized files.
> > > >
> > > > fat32 only supports up to 4GB.
> > > >
> > > > ntfs supports up to 16EiB (Exabytes)!
> > > >
> > > > You could also try using the cp command in a terminal to copy the
> > > > file and see if that gives you a meaningful error message.
> > > >
> > > > Hope this helps.
> > > >
> > > > Regards,
> > > > Tony.
> > > >
> > > > --
> > > >
> > > > Tony Arnold MBCS, CITP | Senior IT Security Analyst | Directorate
> > > > of IT Services | G64, Kilburn Building | The University of
> > > > Manchester | Manchester M13 9PL | T: +44 161 275 6093 | M: +44
> > > > 773 330 0039 
> > > 
> > > Thank you, Tony.
> > > 
> > > I believe that you have provided the answer, from which, I can
> > > derive the solution.
> > > 
> > > I was trying to move the file from the computer internal HDD, which
> > > has most of the Linux partitions, including the home partition,
> > > where the file is located, as ext4.
> > > 
> > > I was trying to move the file to a USB thumbrive - 256GB, which,
> > > from this, I assume to be formatted to FAT32.  
> > 
> > This is your problem.  You need to reformat the USB thumbrive to
> > NTFS, which will handle files > 4G.
> 
> In the past I've had Windows complain about NTFS drives formatted under
> linux. Reformatting under Windows kept Win happy. Would it be better to
> use ext4 if it is just a backup for linux? [And - is this an older
> problem that has been fixed now so Win never complains?]

I had presumed that the use of the USB thumbrive was for transport [to 
MS-Windows or MacOSX], but if it is just a Linux backup and/or transport to 
another Linux machine, then most certainly format it with ext4.

I have used ntfs-3g and ntfsprogs (version 2017.3.23-6.el6.x86_64) under 
CentOS 6 to create NTFS file systems, that at least my Sony BluRay player is 
perfectly happy to read.  (I don't have any reason to deal with MS-Windows for 
any purpose.)

I suspect that newer versions of the ntfs support packages under Linux work 
better [unless M$ comes up with new ways to break things, just because they 
can].

> 
> > > 
> > > I could not use the cp command, as the USB drive name includes a
> > > space, which is not recognised as a character within a directory
> > > name, by command line commands (or so I believe).  
> > 
> > Spaces are allowed in file and directory names.  The *shell* however 
> > recognises space as a word separater, so you need to escape it,
> > either using single quotes (') or backslashes (\).
> > 
> > > 
> > > So, the solution appears to be to get another drive - that I can
> > > rename, to ensure that it does not include spaces in the drive name,
> > > and, format it to either ext4 or NTFS, before writing to it.
> > > 
> > >   
> > 
> 
> 

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller at deepsoft.com       -- Webhosting Services