Re: Parse error - dar does not accept prune directories with trailing slash anymore

Graham Cobb <[email protected]> Mon, 2 Jun 2025 12:05:47 +0100
Newsgroups gmane.comp.sysutils.backup.dar.support
Message-ID <[email protected]>
I *always* type directory paths with a trailing slash. Mostly for the 
reason John gives but also because that is the way my mind works while I 
am typing filenames (probably inherited from my earlier RSX and VAX/VMS 
experience where directories are entered differently if you are 
operating on the directory or the files within it).

While I realize that I could leave the trailing slash out, after over 40 
years of using Unix I don't think I can retrain my fingers!

I would certainly prefer if it was possible to fix the DAR filtering 
problem without breaking trailing slashes.

Regards
Graham

On 01/06/2025 20:53, John Goerzen via Dar-support wrote:
> I'll just note that a lot of shell expansion will add the trailing slash
> for directories.  It is also something I often use when I want to force
> something to be a directory; for instance, "mv foo bar/" ensures that I
> don't overwrite a file named bar with the file named foo, and instead
> move foo into the directory named bar.
> 
> - John
> 
> On Sun, Jun 01 2025, Denis Corbin wrote:
> 
>> Hi Thomas,
>>
>> Changelog for 2.7.17 reports
>> - fixed bug where -R path ending with // was breaking the path filtering
>>    mechanism (-P/-g/-[/-] options).
>>
>> see commit 503326bf8735d8eab48d4ff0ab9c000ffa031dec
>>
>> The fix was needed for the filtering mechanism to work with those uncommon but
>> valid paths (some//path)... sorry if this impacts training slashes. Is it a big
>> problem to avoid using trailing slash in paths?
>>
>> Regards,
>> Denis
>>
>> On 01/06/2025 16:53, Thomas wrote:
>>> Hi!
>>> ;TLDR
>>> =====
>>> With v2.7.17 and later one can't use '-P cdrom/' anymore. Dar aborts
>>> with the error message:
>>> ,---- [  ]
>>> | Parse error: cdrom/ is an not a valid path: Empty string as subdirectory
>>> | does not make a valid path
>>> `----
>>> The following works:
>>> '-P cdrom'
>>> or
>>> '-P cdrom/*'
>>> Bug or feature?
>>> Long version
>>> ============
>>> I have a couple of directories I wan't to have in the backup but without
>>> the files.
>>> I used for a long time for example '--empty-dir -P cdrom/' without
>>> problems.
>>> Now with v2.7.17 and v2.7.18 I only get en error message:
>>> ,---- [  ]
>>> | Parse error: cdrom/ is an not a valid path: Empty string as subdirectory
>>> | does not make a valid path
>>> `----
>>> What went wrong? The message does not enlighten me. I would say cdrom/
>>> is a perfect path and is not empty either.
>>> How to reproduce:
>>> -----------------
>>> export BASE=/tmp/dar_debug
>>> mkdir -p ${BASE}/bak ${BASE}/files/cdrom
>>> touch ${BASE}/files/file1 ${BASE}/files/cdrom/cdromfile1
>>> dar --version
>>> dar --create ${BASE}/bak/full_with_slash    --empty-dir --fs-root ${BASE}/files/ -P cdrom/
>>> dar --create ${BASE}/bak/full_wo_slash      --empty-dir --fs-root ${BASE}/files/ -P cdrom
>>> dar --create ${BASE}/bak/full_with_asterisk --empty-dir --fs-root ${BASE}/files/ -P cdrom/*
>>> Results with v2.7.16
>>> --------------------
>>> All three create-commands are working as expected. They generate a
>>> backup file including file1 and an empty cdrom directory.
>>> cdromfile1 is not included as expected.
>>> dar --list ${BASE}/bak/full_with_slash
>>> [Data ][D][ EA  ][FSA][Compr][S]| Permission | User  | Group | Size    |          Date                 |    filename
>>> --------------------------------+------------+-------+-------+---------+-------------------------------+------------
>>> [Saved][ ]       [---][     ][ ]  -rw-rw-r--   1000	1000	0	Sun Jun  1 12:49:26 2025	file1
>>> [Saved][-]       [---][     ][ ]  drwxrwxr-x   1000	1000	0	Sun Jun  1 12:49:26 2025	cdrom
>>> dar --list ${BASE}/bak/full_wo_slash
>>> [Data ][D][ EA  ][FSA][Compr][S]| Permission | User  | Group | Size    |          Date                 |    filename
>>> --------------------------------+------------+-------+-------+---------+-------------------------------+------------
>>> [Saved][ ]       [---][     ][ ]  -rw-rw-r--   1000	1000	0	Sun Jun  1 12:49:26 2025	file1
>>> [Saved][-]       [---][     ][ ]  drwxrwxr-x   1000	1000	0	Sun Jun  1 12:49:26 2025	cdrom
>>> dar --list ${BASE}/bak/full_with_asterisk
>>> [Data ][D][ EA  ][FSA][Compr][S]| Permission | User  | Group | Size    |          Date                 |    filename
>>> --------------------------------+------------+-------+-------+---------+-------------------------------+------------
>>> [Saved][ ]       [---][     ][ ]  -rw-rw-r--   1000	1000	0	Sun Jun  1 12:49:26 2025	file1
>>> [Saved][-]       [---][     ][ ]  drwxrwxr-x   1000	1000	0	Sun Jun  1 12:49:26 2025	cdrom
>>> Results with v2.7.17 and v2.7.18
>>> --------------------------------
>>> The first create command failes with the error message above.
>>> The second and third are working as expected.
>>> dar --list ${BASE}/bak/full_with_slash
>>> No backup file is present in file:///tmp/dar_debug/bak for archive
>>> full_with_slash, please provide the last file of the set. [return = YES | Esc
>>> = NO]
>>> dar --list ${BASE}/bak/full_wo_slash
>>> [Data ][D][ EA  ][FSA][Compr][S]| Permission | User  | Group | Size    |          Date                 |    filename
>>> --------------------------------+------------+-------+-------+---------+-------------------------------+------------
>>> [Saved][ ]       [---][     ][ ]  -rw-rw-r--   1000	1000	0	Sun Jun  1 12:49:26 2025	file1
>>> [Saved][-]       [---][     ][ ]  drwxrwxr-x   1000	1000	0	Sun Jun  1 12:49:26 2025	cdrom
>>> dar --list ${BASE}/bak/full_with_asterisk
>>> [Data ][D][ EA  ][FSA][Compr][S]| Permission | User  | Group | Size    |          Date                 |    filename
>>> --------------------------------+------------+-------+-------+---------+-------------------------------+------------
>>> [Saved][ ]       [---][     ][ ]  -rw-rw-r--   1000	1000	0	Sun Jun  1 12:49:26 2025	file1
>>> [Saved][-]       [---][     ][ ]  drwxrwxr-x   1000	1000	0	Sun Jun  1 12:49:26 2025	cdrom
>>> Something between v2.7.16 and v2.7.17 has changed.
>>> I would say this is a bug but it could be intentional. So my question
>>> is:
>>> Is it a bug or a feature?
>>> Thanks for your support.
>>> Tom
>>>
>