Recurrent issue with invalid filenames while copying files to external disk

Support & Help Requests
1

I was copying files from home directory, and encountered a recurrent issue that Ubuntu failed to copy files/directories due to some "invalid filename". I had this issue before, then the copying error was related to some slashes and colons present in filenames, so since then I had been saving files avoiding these symbols in filenames.

But now there's the same issue with relatively regular filenames (error while creating these folders due to invalid filename). It refused to copy the following files/directories:

/home/usrn/Desktop/COURSES/Coursera2024/Learning How to Learn Powerful mental tools to help you master tough subjects/Module 2/2.2_Seeing_the_Bigger_Picture/6_Quiz_Retrieval Practice

/home/ursn/Desktop/COURSES/edX_007/Biobased Products for a Sustainable (Bio)economy/5. Biobased products Biosurfactants/5.2 (Bio)surfactants what? where? how?

/home/usrn/Desktop/COURSES/edX_007/Sustainable Energy/Week 3 Economic Feasibility Assessment/Unit 2 Costing a Nuclear Power Plant

/home/usrn/Desktop/COURSES/LinkedInLearning_007/LL_007/ACCOUNTING/Accounting Foundations Understanding accounting cycle and accrual based accounting

It seems I have many similar directories with either underscores or spaces in their names, and they have been copied just fine. I will modify these directories so that they would be copied, but it's a bit annoying to think about directory names every time big chunks of files are being copied to disk.
What can be a potential cause of this issue in Ubuntu Mate 22.04. 05 LTS ?
Are the names of some folders too long to copy?

P.S. As I was creating some of the dubdirectories, i was copying the names from a web page, so there may have been some invisible symbols present like new line or something from page's HTML, which are hindering the copy procedure.

2

What format is the external disk? I'm going to guess NTFS (Windows)?

Once we know, then it could be due to long names, or maybe there are hidden characters embedded in the filename. Will it copy if you rename the file and then try again?

2 Likes
3

Provided that you are using EXT4 filesystem, such the errors may be result of the source or target file name length. There is some confusion though. They say that file name max length is 255 characters and full path name max length is 4096 characters. Different sources claim that max path name length is 255 characters. Nevertheless, file name/path limitations are the first candidates to cause the error.

Verify your file/path name max length using

$ getconf -a | grep -i name_max
NAME_MAX                           255
...
$ getconf -a | grep -i path_max
PATH_MAX                           4096
_POSIX_PATH_MAX                    4096
$

And yes, special characters in file names can cause errors as well for the reason that they require special handling.

3 Likes
4

Yes, the filesystem on the portable disk is NTFS (it was installed by default). I removed the hidden characters (new line) already.

5

Provided NTFS target disk, the problem is probably special characters in the source file path/name. In particular


    < (less than)
    > (greater than)
    : (colon)
    " (double quote)
    / (forward slash)
    \ (backslash)
    | (vertical bar or pipe)
    ? (question mark)
    * (asterisk)

More details are in

2 Likes
6

I have the same path_max and name_max as mentioned (4092, 255). It seems like no path would have exceeded 4092

7

I've got one path mistyped. Some of the paths not copied are:

/home/usrn/Desktop/COURSES/Coursera2024/Learning How to Learn Powerful mental tools to help you master tough subjects/Module 2/2.1_Chunking_the_Essentials/7_ Quiz_Retrieval Practice

/home/usrn/Desktop/COURSES/FreeCodeCamp_cert/Data Analysis with Python Certification/1.Data Analysis with Python/13.Pandas Introduction/13. freecodecamp-intro-to-pandas

So for some reason it doesn't parse the paths containing consecutive underscore and a space "_ ".

8

I believe the main issue is that unless you are using single/double quotes around the fullpath name of files, regardless of Windows/Linux, the system will assume the first space is the end of the filename, the remainder the second/third filename, and the last the target directory (because of multiple names parsed due to the non-escaped spaces).

If the issue is the depth of the source directory (exceeding max character limits), perform a "cd" into that directory and perform a copy that is relative. Likewise if the issue is the depth of the target directory (exceeding max character limits).

If the characters are acceptable, but you are only dealing with spaces in the names (as long as it is allowed for that filesystems), then something like

cd "${sourceDir}" ; tar cf - . | ( cd "${targetDir}" ; tar xvpf - )

will allow you to maintain those spaces in the file names without resorting to quotations for copying individual filenames. HOWEVER, you do need them on the directory names in the above command.

If you create a full (text-based) index of you files (eg. a sorted list of all files under "/" ), you could adapt the script that I have published at

for your own context/needs. :slight_smile:

2 Likes