Ctrl-C/Ctrl-V problem with very long paths

Hello,
I am using your program (currently version DOpusInstall-12.10-beta-x64) only because it supports more than 256 characters.
A file must not be longer than 255 characters (see https://resource.dopus.com/t/rename-a-file-with-more-than-256-chars-in-its-name/27509), but there are still problems copying and moving files with (only) 232 characters if the number of characters in the filename + the number of characters in the path are longer than 255 characters.
Example:
In the

"C:\TEMP! short-temp!!!!!!!!!!!!!!!!!! TEST with NEW VERSION DOPUS -" copy or move !!!!!"

I created a text file with the name

"18-09-21¦10.46¦ --» AAAAAAAAA Bbbbbb - concerning 2016 KÜ- CCCCCCCCC - Abcdef aaa bbbbbbb cccccccccc 7th edition § 313 Rn 87,111,169,170, -- AW ABBBBBBBB Ccccccccc Dddddddddd m Eeeeeeeeeeee Fffff -WG HERE 18-09-19¦17.44¦--"SS-Eeeeeeeee-v02-mÄM.txt".

If I "copy" this file in the same directory, this file will not be copied, but the original file will be renamed to "18-09-~1.TXT". When I update the directory, the name of the original file appears again (Attention: on the first attempt this file was even DELETED!), but it was NOT copied.
If I copy this file into a subdirectory "copy-Dir", the file there will only get the name
"18-09-~1.TXT" (even after update).

When moving the file
"18-09-21¦10.46¦ --» AAAAAAAAA Bbbbbb - concerning 2016 KÜ- CCCCCCCCC - Abcdef aaa bbbbbbb cccccccccc 7th edition § 313 Rn 87,111,169,170, -- AW ABBBBBBBB Ccccccccc Dddddddddd m Eeeeeeeeeeee Fffff -WG HERE 18-09-19¦17.44¦--"SS-Eeeeeeeee-v02-mÄM.txt"
into the subdirectory "copy-Dir" it works IN THIS CASE (the long file name is displayed in the target directory). But I already had the opposite problem in other directories: While moving the short file name "18-09-~1.TXT" came up, but copying worked correctly.

If I remember correctly, these problems didn't exist in DOpus12.6. In version 12.6 I had only noticed the problem described at https://resource.dopus.com/t/rename-a-file-with-more-than-256-chars-in-its-name/27509, but according to Jon's comment this was (also) due to the number of characters in the filename and from that point on I didn't give more than 256 characters to a filename.
As described, since some updates copying and moving files with less than 255 characters doesn't work either.
But maybe I don't really remember this anymore, because I wrote back then:
"Jon, thanks (good link!). But the problem IT'S NOT ONLY the file Name length BUT ALSO about path lengths including folders (AND/ WITH long file names, too)."

This might not only be a huge problem for me.
I would be very, very grateful for fixing this bug.

Thx. & Best regards
Alex

How are you doing the copy?

Ctrl-C/V seems to do that, you're right. We'll look into that. (The old file is not really being renamed; it's showing the short file name for some reason until a refresh.)

But using the Copy Files > Duplicate command works fine, as an alternative.

You should aim to avoid creating files with names or paths longer than 255 characters because it will cause problems (ranging from odd things like this, to full crashes) in a huge amount of software and parts of the OS itself. We aim to make the main areas of Opus work with them, since they occur sometimes unintentionally and people need to be able to do basic file management on those files when they arise (even if it's just to move/rename them to shorter names/paths), but they are not something you should intentionally create.

Hi Leo,

Yes, I made the copy with Ctrl+C and Ctrl+V.

"The old file is not really being renamed; it's showing the short file name for some reason until a refresh."

Please note that I didn't want to rename the old file/the original file at all, but only wanted to copy it into a new file - but the new file doesn't appear at all.

The duplicating worked, I have to exchange the keyboard shortcut somewhere ...

FYI: By the way, if not in the current example I had the problem with shortening the file names, especially when moving files (interestingly, but not in the example). The problem in this case is that you don't know the original filename anymore(!) and you only see an abbreviation in the target directory.
Maybe you could check it as well.

[ By the way, I am dependent on working with numerous subdirectories (keyword: different structures), so that the total length of the directories often exceeds 255, which I cannot change. NTFS basically supports 32,000 characters, only the WIN people prefer to imitate things from other companies instead of doing their own homework once ].

small Addition :wink:
... one more hint/request: It might be very convenient (I think for other users, too) to provide the following two "codecs" at the status bar:

  1. codec: number of characters of the current file;
  2. codec: number of characters of the current file together with (= plus +) the characters of the total (upper) file path;
    ... so you could quickly see not only the number of characters of a single file, but also the number of characters of a single file including the number of characters of the overall folder path above, at a glance in the status bar.

It would be very, very helpful - especially to avoid error messages at the beginning of the process even when renaming files !

There is a path length column for that.

The column path length I found but not the hcolumns of the number of characters of the files in a directory. What is the column name, please?

You could go into the folder and sort by the path length column to find that information.

A script column could also do it.

sorry Leo,
but I would find out/see only the lenght of characters of (only) a file regarding the file must not be longer than 255 characters if I want to rename or copy this file in the SAME Directory.
I often see an error. If I could see the characters of the original file (without the path-characters), then I could estimate from the outset whether the length of the copied target file has perhaps more than 255 characters before copy the original file. - I can't see this immediately with the path length specification, but would have to calculate out the file length laboriously.
What do you mean by a script column? Do you have a link? Because in folder options I didn't find anything with scripts. How is that supposed to work?
Thank you very much.

Hi Leo,
in this case I see again another Problem:
If I copy or move the file:

19-01-04¦11.59¦ --» EINGANG xx. xxxxxxx - Verfügung StA xxxxxxx x v. 02.01.2019 - 'Die xxx geht nach wie vor nicht vom Vorliegen Vss- § 235 Abs. 4 StGB aus - iÜ reicht Strafgewalt Strafrichter gem. 24 II GVG ebenso weit, wie Schöffengericht.pdf

(with 241 characters without the Extension PDF - do I have to count the extension concerning the 256 or 260 character length, too)?

to Directory (= a Win-'SUBST'-Directory):

S:\StrafR\2014\080723-14\05 KK mit Instanzen-02-Anklageverfahren + ! KK dbzgl. mit RA !

the result of the copy in this target directory is a file with the Name:

19-01-~2.PDF

An other interesting thing is this: If I manually rename the file in the target directory correctly again and then copy the same file with the same name:

19-01-04¦11.59¦ --» EINGANG xx. xxxxxxx - Verfügung StA xxxxxxx x v. 02.01.2019 - 'Die xxx geht nach wie vor nicht vom Vorliegen Vss- § 235 Abs. 4 StGB aus - iÜ reicht Strafgewalt Strafrichter gem. 24 II GVG ebenso weit, wie Schöffengericht.pdf

from the source directory into the target directory again, Dopus does NOT ask if I want to replace the file already existing with the same file name, but creates a new file with the name:

19-01-~2.PDF

This is a little strange :wink: - Maybe the developers can fix this problem ...
Thanks a lot.

Addendum: Dopus even seems to have a limitation of the characters of a filename (with extension) not 256 or 260 but to 251 characters. Because this file:

19-01-02¦11.44¦ --» EINGANG Gr-AW 'Pfad wird bei jeder manu-Sicherung v Assistenten gespeichert. Habe so geändert, dass stets normale Langpfad verwendet w' bzgl. Problem 'Nr. 53-Datei nicht gefunden'»Pfadangabe 'datenserver--kanzlei-store--S9IRTS.msg

has (with extension) 251 characters, without the dot and the extension even only 247 characters and you cannot add any more character when renaming (otherwise error).

I created a file with 251 characters in the name and then renamed it to 255 and it was successful:

We'll fix the Ctrl-C/Ctrl-V thing in the next update.

Here's a simple script that adds a name length column. Install it by copying the file to the /dopusdata/Script AddIns folder.

NameLength.vbs.txt (706 Bytes)

Hi Jon,

thank you for the sript, I will try it.

But concerning:
Jon: I created a file with 251 characters in the name and then renamed it to 255 and it was successful:

it's possible for me, too. - But only in the example directory:

C:\TEMP! kurz-temp

--» THERE I can create and rename a file to:

19-01-02¦11.44¦ --» EINGANG Gr-AW 'Pfad wird bei jeder manu-Sicherung v Assistenten gespeichert. Habe so geändert, dass stets normale Langpfad verwendet w' bzgl. Problem 'Nr. 53-Datei nicht gefunden'»Pfadangabe 'datenserver--kanzlei-store--S9IRTS12456.msg

(with 256 characters INCLUDED the Extension).

BUT it's NOT possible for me in the example directory:

S:\StrafR\2014\080723-14\05 KK mit Instanzen-02-Anklageverfahren + ! KK dbzgl. mit RA !

and also NOT in the directory:

\\DATENSERVER\10 KANZLEI - Intern\10 - TECHNIK - Administration\¦-» WINDOWS\A - AJur + Konfiguration\KK mit XYZ

Which drive/server types are those? Is a NAS ir other non-Windows machine involved?

Drive S:\
... is a SUBST-Drive (https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/subst) which is connected to a LINUX server via a network Connection.

\\DATENSERVER\10 KANZLEI - Intern\10 - TECHNIK - Administration\¦-" WINDOWS\A - AJur + Konfiguration\KK mit XYZ
... is the direct specification of the network connection to the LINUX server ('\\DATENSERVER' = the Linux file server).

The server may be enforcing a path limit. Does what you're doing work with the same path in anything else?

Reiterating what a said before, you will run into issues using such long paths, even if the issues are not in Opus. They are best avoided, not created on purpose.

OK. I've found the solution to why this problem exists: The Linux server didn't have a "path" problem, especially not in limiting, but a "name" problem with certain Windows ANSI special characters in the name of files that are stored by Windows over network on a LINUX server.
I'll explain it here in as much detail as possible to help other users affected by this problem:

(1) Windows displays all special characters without problems and/or conversinon that are contained in the Windows ANSI character table.

(2) Linux has - especially not e.g. in the ext4 file system - no ANSI character table, but only an ASCII character table.

(3) In Linux, only 255 characters may be contained in a file name, too. See: https://wiki.ubuntuusers.de/Dateisystem/#Weitere-Merkmale.

(4) In Windows the file name:

19-01-02¦11.44¦ --» EINGANG Gr-AW 'Pfad wird bei jeder manu-Sicherung v Assistenten gespeichert. Habe so geändert, dass stets normale Langpfad verwendet w' bzgl. Problem 'Nr. 53-Datei nicht gefunden'»Pfadangabe 'datenserver--kanzlei-store--S9IRTS.msg

has exactly 250 characters (with Windows ANSI special characters).

(5) If you save this file under Linux, it is visible in a file manager (where at least UTF8 is set by default), also EXACTLY SO with 250 characters.

(6) BUT: This file is stored under Linux in ASCII character format. If you display THIS FILE in ASCII format, you get the following file name:

19-01-02¦11.44¦ --» EINGANG Gr-AW 'Pfad wird bei jeder manu-Sicherung v Assistenten gespeichert. Habe so geändert, dass stets normale Langpfad verwendet w' bzgl. Problem 'Nr. 53-Datei nicht gefunden'»Pfadangabe 'datenserver--kanzlei-store--S9IRTS.msg

This file name stored on the LINUX server has exactly 255 characters, so that neither LINUX nor Windows over network (where only 250 characters are displayed, see above) can add only a single character to this file name via the network.

Why?
It is probably because these Windows ANSI special characters contained in the file name do not exist in the LINUX ASCII table and LINUX AUTOMATICALLY converts these characters and places its own characters in front of them.

RESULT: Even if the file name of a file stored over network on a LINUX server contains only 250 characters in the file manager of Windows, 5 characters cannot be added to this file name, because the same file on the LINUX server already has the maximum number of 255 characters.

Well, the Windows and LINUX world is sometimes not easy (...).

Jon Directory Opus developer 1 Jan 9, 2019
[...]
Here's a simple script that adds a name length column. Install it by copying the file to the /dopusdata/Script AddIns folder.

Hi Jon, regarding your above message of 1 Jan 2019: Can you please tell me the variable I can use in this script to specify the COLOR of the numbers displayed in the column (e.g. color red)?
Thx. a lot

Script columns cannot change color based on their values. (Except if they display bar graphs rather than text. You could have a graph of path length 0-255 or similar, which turned red, if you wanted that.)

This would be better discussed in a separate thread if you want to take it further, since it's not really related to "Ctrl-C/Ctrl-V with very long paths".

OK, see new thread, zip. By the way, I don't mean the color of every single displayed number, but (all in all) ALL numbers displayed in this column, which you can usually set under -> Preferences -> Display -> Fields, but the column from the script is not visible here)