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
