Re: Kernel 6.6.17-LTS breaks almost all bash scripts involving a directory

[Greg KH <gregkh@linuxfoundation.org>]

On Mon, Feb 26, 2024 at 10:52:50AM -0500, Konstantin Ryabitsev wrote:
> > In the past 4 or 5 years I've been using this script (with an alias) to
> > compress a single folder:
> > 7z a "$1.7z" "$1"/ -mx=0 -mmt=8
> > 
> > I know it doesn't look like much but essentially it creates a 7z archive
> > (with "store" level of compression) with a name I've entered right after the
> > alias. For instance: 7z0 "my dir" will create "my dir.7z".
> > And in the past 4 or 5 years this script was working just fine because it
> > was recognizing the slash as an indication that the target to compress is a
> > directory.
> > However, ever since 6.6.17-LTS arrived (altough I've heard the same
> > complaints from people who use the regular rolling kernel, but they didn't
> > tell me which version) bash stopped recognizing the slash as an indication
> > for directory and thinks of it as the entire root directory, thus it
> > attempts to compress not only "my dir" but also the whole root (/)
> > directory. And it doesn't matter whether I'll put the slash between the
> > quotes or outside of them - the result is the same. And, naturally, it
> > throws out an unlimited number of errors about "access denied" to everything
> > in root. I can't even begin to comprehend why on Earth you or whoever writes
> > the kernel would make this change. Forget about me but ALL linux sysadmins I
> > know use all kinds of scripts and changing the slash at the end of a word to
> > mean "root" instead of a sign for directory is a rude way to ruin their
> > work. Since this change occurred, I can no longer put a directory in an
> > archive through CLI and I have to do it through GUI, which is about 10 times
> > slower. I have a DE and I can do that but what about the sysadmins who
> > usually use linux without a DE or directly SSH into the distro they're
> > admins of? With this change you're literally hindering their job!
> > 
> > I downgraded the kernel to 6.6.15-LTS and the problem disappeared - now the
> > slash is properly recognized as a sign for directory.


Any chance you can run 'git bisect' to find the offending commit?

Also, what filesystem type are you seeing this issue on?

thanks,

greg k-h