retrieve data "from the archive" generated by filetags

[nbehrnd]

The current version's header reads like a retrieval of the original files (or copies of them) once was envisioned (--copy flag), but either was not yet implemented, or is a feature (sadly) retracted. However, it would be a feature very welcome to facilitate e.g., access and subsequent share copies of non-image data stored at different dates in the archive (by move2archive).

Ad hoc , I identified the following approach working well enough. Perhaps parts of it can be used for the suggested feature extension:

• enter the archive, e.g. and generate as usual a directory of file links, e.g.,

~/archive$ filetags --recursive --filter
                 
Please enter tags, separated by " "; abort with Ctrl-C
                     
         .--------, 
        | o   ?   | 
         `--------' 
                     
Tags: dw

INFO     filtering items with tag(s) "dw" and linking to directory "/home/norwid/.filetags_tagfilter" ...
 linking  "2022-05-17_dw550x__new_sketcher_icons -- dw updater.zip"
             ⤷   ".filetags_tagfilter"
 linking  "2022-05-21_molecules -- dw linked.dwar"
             ⤷   ".filetags_tagfilter"
 linking  "2022-05-21_example_str_skelspheres -- dw linked.png"
             ⤷   ".filetags_tagfilter"
[...]

• Loop over the links which Python (now) may recognize as such (stackoverflow) and use to fetch copies with os.readlink() eventually resolved as self-sufficient files one may forward and share again:

~/.filetags_tagfilter$ python3 ./script.py

where script.py basically is

#!/usr/bin/env python3

"""Convert filetags' links into real files"""

import os
import shutil


for element in os.listdir("."):
    if os.path.islink(element):
        # get an intermediate «full file»
        new_name = "".join([os.path.basename(element), "_b"])
        shutil.copy(os.readlink(element), new_name)

        # remove the links from the folder
        os.remove(element)

# establish the original names:
for element in os.listdir("."):
    if element.endswith("_b"):
        shutil.move(element, str(element)[:-2])

The observations refer to Linux Debian 12/bookworm with Python 3.10.7 and the filetags executable reporting 2022-01-24 as last time of modification.

[novoid]

Hi,

I'm not sure if I understand your request. Can you describe the motivation (what do you want to achieve in your daily digital life?) and perhaps a "before invocation" and "after invocation" minimal example?

It looks to me as if you want to replace existing links of a filter result with copies of the files instead of links. If I would like to have this, I'd probably use the -L flag of the cp command:

user@computer ~2d/2022-09-28 symlink cp test % mkdir src
user@computer ~2d/2022-09-28 symlink cp test % mkdir dst
user@computer ~2d/2022-09-28 symlink cp test % cd src 
user@computer ~2d/2022-09-28 symlink cp test/src % l
total 8
drwxrwxr-x 2 vk vk 4096 Sep 28 14:57 .
drwxrwxr-x 4 vk vk 4096 Sep 28 14:57 ..
user@computer ~2d/2022-09-28 symlink cp test/src % touch "original.txt"
user@computer ~2d/2022-09-28 symlink cp test/src % ln -s original.txt link_to_original.txt
user@computer ~2d/2022-09-28 symlink cp test/src % echo "Foo" > original.txt 
user@computer ~2d/2022-09-28 symlink cp test/src % l
total 12
drwxrwxr-x 2 vk vk 4096 Sep 28 14:57 .
drwxrwxr-x 4 vk vk 4096 Sep 28 14:57 ..
lrwxrwxrwx 1 vk vk   12 Sep 28 14:57 link_to_original.txt -> original.txt
-rw-rw-r-- 1 vk vk    4 Sep 28 14:57 original.txt
user@computer ~2d/2022-09-28 symlink cp test/src % cd ..
user@computer ~2d/2022-09-28 symlink cp test % cp -L src/link_to_original.txt dst 
user@computer ~2d/2022-09-28 symlink cp test % l dst/
total 12
drwxrwxr-x 2 vk vk 4096 Sep 28 14:58 .
drwxrwxr-x 4 vk vk 4096 Sep 28 14:57 ..
-rw-rw-r-- 1 vk vk    4 Sep 28 14:58 link_to_original.txt
user@computer ~2d/2022-09-28 symlink cp test % cd dst/
user@computer ~2d/2022-09-28 symlink cp test/dst % cat link_to_original.txt 
Foo
user@computer ~2d/2022-09-28 symlink cp test/dst % 

... this should get the expected result if I did understand your goal correctly.

[nbehrnd]

The motivation is similar to «export and hand me over all archived invoices of 2022 tagged both with `acquisition` .and. `housing`». In this perspective, affirmative yes, instead of symlinks created in the first round, the intent is to recover copies of the files stored in the archive, which would allow me to send these copies of files e.g., as an attachement to my landlord. For me, this result is close to filetags' todo (line 11) in __init.py__ reading ``` - tagfilter: --copy :: copy files instead of creating symlinks ```

[novoid]

From my perspective you have two options:
Either you're using the cp -L pattern shown above or you're using the --hardlinks option (for non-Windows).

This is probably also a reason why I didn't prioritize the --copy idea.

Otherwise, this is potentially a duplicate of #10

[nbehrnd]

Speaking for Linux Debian 12, running --filter --hardlinks indeed yields
copies of the files; this fits very well my needs.

As a side note, replicating the snippet shared by you has the constraint that
the link breaks this one when cp -L puts it as a copy from src in dst.
This is in the report by ls -l where the l (ell) in the block of permissions
is substituted by the dash. In addition (coherent with the dropped l in ls
listing) and contrasting to the link still in the same folder (src), the one in
folder dst is a frozen snapshot. To still access the file from the other
folder, one approach is 1) to alter the relative link to be an absolute one
and 2) move this one to the new place; both steps assume the OS offers this
functionality.

record.txt

[novoid]

Caution: hardlinks are no copies. They are within-partition links to the very same file. In contrast to copies, each hardlink representation gets modified when you modify one instance of its links.

I'm sorry to write that I can't follow your side note. I don't get what is not working as expected/shown above on your side.