Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CLI parameter to switch between: use symlink, hardlink, or copy #10

Open
novoid opened this issue Apr 19, 2018 · 4 comments
Open

CLI parameter to switch between: use symlink, hardlink, or copy #10

novoid opened this issue Apr 19, 2018 · 4 comments

Comments

@novoid
Copy link
Owner

novoid commented Apr 19, 2018

Non-Windows systems do not only know lnk files but also symbolic links and hard links.

I'd like to be able to choose for tagtrees and filter functionality whether or not (1) lnk files or symlinks are being used (2) hard links are used or (3) file get copied instead.

@novoid
Copy link
Owner Author

novoid commented Dec 19, 2021

Support for hardlinks got added with 49179d4.

@novoid
Copy link
Owner Author

novoid commented Dec 19, 2021

Negative impact of using copy instead of links need to be investigated. This could really fill up disk space easily. Therefore, I'm unsure if this idea is still worth following.

@nbehrnd
Copy link
Contributor

nbehrnd commented Oct 2, 2022

As a comment:

  • Running out of physical space in a partition, or available index nodes (which may occur early when processing many small files) may be recognized as OSError Python reports back in lines of «disk full».

  • Running filetags with Linux Debian 12 in lines of

~/archive$ filetags --filter --hardlinks --recursive 

(already) yields self sufficient files one may sent e.g., by email to a colleague (if the OS supports hardlinks); this equally may «saturate» a disk partition/thumb drive.

On the other hand, if I drop --hardlinks and subsequently access the folder of links filetags created, file manager Thunar both states the number of the files .and. the size of the files the links point to (e.g., 7.1MB) -- though the folder's content (i.e., the links) is much smaller (e.g., du -h reports 132K). So filetags already offers (an implicit) approach to avoid disk saturation by criterion of volume when retrieving the files.

2022-10-02T12 10 48 -- screenshots

@novoid
Copy link
Owner Author

novoid commented Oct 2, 2022

Careful: when using hardlinks, the situation is somewhat non-intuitive for somebody not familiar with the implementation details of symbolic and hard links. For example, you get disk usage reported multiple times via listing directory contents (containing hard links) separately although the overall free disk space is not (or minimal) changed. So you can't use this criteria to compare disk usage.

AFAIR symbolic links use one inode size per link and hardlinks may only use a directory entry which is smaller than an inode if I remember correctly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants