cd bug crash
cd into a directory with 60-90 characters in the path and it crashes the session, seems reproducible
I can enter a directory whose names is 76 digits (the 42 first natural integers glued one after the other):
$ mkdir $(seq -s '' 42)
$ cd $(seq -s '' 42)
Depending on the filesystem, there is a maximal number of bytes per file name, 255 bytes for reasonably modern file systems such as the whole ext family, XFS, Btrfs, F2FS, etc. Bad filesystems (FAT32, exFAT, NTFS, etc.) limit the number of characters per path, but the limit is high, e.g., 32760 characters. So, the filesystem should not be the problem here.
Linux's system calls fail if a path in argument is more than 4096 bytes long:
$ grep PATH_MAX /usr/include/linux/limits.h
#define PATH_MAX 4096 /* # chars in a path name including nul */
Nevertheless, absolute paths can actually be longer and relative paths provided to the system calls, as https://eklitzke.org/path-max-is-tricky explains. Anyway, 4096 is much more than the number you mention: the kernel should not be the problem here either.
Maybe your shell prompt includes the name of the working directory. Mine does, but I face no problem entering a directory with many characters. Here it is:
$ echo $PS1
\[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$
In conclusion, I do not know the reason for your problem, but it should not be a system limit or a bug in cd.
> I can enter a directory whose names is 76 digits (the 42 first natural integers glued one after the other):
$ mkdir $(seq -s '' 42)
$ cd $(seq -s '' 42)
I tried the test code you wrote and it instantly crashes the session for me.
I booted from live USB, went to root directory and made a few different directories of different length there to test and established that a directory of just 69 characters after / is sufficient to crash the session.
> Depending on the filesystem, there is a maximal number of bytes per file name [or] characters per path, but the limit is high, e.g., 32760 characters. So, the filesystem should not be the problem here.
The live USB shows it is using the ISO9660 filesystem, not sure exactly what the limitations are for that, but that wouldn't be the problem would it?
(By the way I am also not sure why as an unprivileged user I can start gparted as the superuser. This seems like some sort of escalation of privilege bug to me but I should probably start a new forum topic to address that.)
The live USB shows it is using the ISO9660 filesystem, not sure exactly what the limitations are for that, but that wouldn't be the problem would it?
It is. I thought we were talking about an installed system, using filesystems such as ext4, XFS, Btrfs, etc. https://en.wikipedia.org/wiki/ISO_9660#Directories_and_files says:
The standard specifies three nested levels of interchange (paraphrased from section 10):
- Level 1: File names are limited to eight characters with a three-character extension. Directory names are limited to eight characters. Files may contain one single file section.
- Level 2: Files may contain one single file section.
- Level 3: No additional restrictions than those stipulated in the main body of the standard. That is, directory identifiers may not exceed 31 characters in length, and file name + '.' + file name extension may not exceed 30 characters in length (sections 7.5 and 7.6). Files are also allowed to consist of multiple non-contiguous sections (with some restrictions as to order).
Additional restrictions in the body of the standard: The depth of the directory hierarchy must not exceed 8 (root directory being at level 1), and the path length of any file must not exceed 255. (section 6.8.2.1).
You can install Trisquel on a flash drive, if you wish (you then need the live system on another drive). In this way, the filesystems on the partitions of the flash drive will not have the limits you face. That said, flash drives wear off: make regular backups and do not expect years of use.
That explains it then. Thanks for the advice Magic Banana. I was confused when I encountered this crash behavior because I recall previous Trisquel versions did not crash like this even with the live systems, I think they did not use the ISO9660 filesystem so I am use to the idea that live systems can do everything installed systems can do. Now when session crashes (not just cd) I am not sure what is bug and what is filesystem limitation.
Do you know if there are advantages to using the ISO9660 filesystem why Trisquel started using it?
It is the filesystem for CDs/DVDs, which are still used to run live systems.
The puzzling thing is that when I used live Trisquel systems in the past, I did not experience this limitation. I don't know what filesystem Trisquel used for older live systems, if it was always ISO9660 or something different, but I could cd into long paths without problem with the old live systems.
Isn't it similar to that session-crash problem?
https://trisquel.info/en/forum/x11-close-session-when-opening-file-or-browsing-web