[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Running of rrequested tests - [was Backup problem using "cp"]


Richard Owlett wrote:
> > /home/richard/.local/share/Trash/expunged/1449727740/
> └── grub2 problem-2018-02-13
> ...
> Goes on for 161 directories

The name is 24 bytes long.
Plus one slash yields 25.
161 times 25 = 4025 bytes for the problem directories.
Plus 53 for "/home/...40/" = 4078.
So far your system accepted the path.

But plus 37 for "/media/richard/...sda14" yields 4115 and caused protest.

Google finds me
  #define PATH_MAX 4096	/* # chars in a path name including nul */
My local
says the same.

So Linux publishes a limit of at most 4095 bytes for paths.
Many filesystem will actually have this limit or lower ones. It is not
clear whether you bonked against a fixed limit of Linux or a specific
limit of the particular filesystem on the USB disk.

The origin of this insane directory chain is obscure, of course. Maybe
the name parts "grub2" and "2018-02-13" help Richard to remember what
might have happened back then.

For the purpose of disk sanity (and maybe successful "cp -ax") i'd then
consider to remove these directories.

David Wright made the better initial guess, compared to mine.


> I suspect some of my confusion revolves around not understanding "2>&1".

That's about
- "standard output" (result channel of classical Unix programs
- "standard error" (non-result message channel)
- "redirection" (plugging together such channels)
- "file descriptors" (a programmer's thing, actually) which get set at
  program start to:
    0 = standard input (the channel for input text, normally your keyboard)
    1 = standard output (normally your terminal)
    2 = standard error (normally your terminal, too)

All together "2>&1" funnels the non-result messages of a program into the
result channel. This is done typically before a pipe that consumes standard

  program 2>&1 | other_program

or _after_ a redirection of standard output to a file

  program >log_file 2>&1 

In both cases it shall join both output channels into a single channel.

(If you write "program 2>&1 >log_file" the non-result messages will
 appear on the former standard output and the results will go into the
 file "log_file". Sequence matters.)

Have a nice day :)


Reply to: