Please describe the problem.
"directory" special remote leaves empty directories after dropping files. I compared it to rsync, and he cleans empty dirs, so I wonder if this is a bug in "directory".
Also I think is it possible to make testremote
also test for it? First I
found this behavior in rclone special remote and was very confused, then
compared to "directory" and got confused even more.
What steps will reproduce the problem?
I made a little script :D, here it is:
#!/bin/bash
test_dir=$(mktemp -d /tmp/test-empties.XXX)
cd "$test_dir" || exit 1
# create repo
mkdir rep && cd rep || exit 1
git init
git annex init
# add special remotes
mkdir ../sp_directory
git annex initremote sp_directory type=directory directory=../sp_directory encryption=none
git annex initremote sp_rsync type=rsync rsyncurl=../sp_rsync encryption=none
# add file and copy to remotes
touch a
git annex add a
git commit -m commit
git annex copy a --to sp_directory
git annex copy a --to sp_rsync
test_it() {
name="$1"
echo -e "\n\n"
echo "--------- special remote: $name ---------"
echo "--------- before drop: ---------" && tree "../sp_$name"
echo
git annex drop a --from "sp_$name" --force
echo
echo "--------- after drop: ---------" && tree "../sp_$name"
}
test_it directory
test_it rsync
What version of git-annex are you using? On what operating system?
git-annex version: 10.20230626-g55fef4fb81
OS: archlinux
Please provide any additional information below.
Output of my script:
<cut>
--------- special remote: directory ---------
--------- before drop: ---------
../sp_directory
├── f87
│ └── 4d5
│ └── SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
│ └── SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
└── tmp
5 directories, 1 file
drop sp_directory a ok
(recording state in git...)
--------- after drop: ---------
../sp_directory
├── f87
│ └── 4d5
└── tmp
4 directories, 0 files
--------- special remote: rsync ---------
--------- before drop: ---------
../sp_rsync
└── f87
└── 4d5
└── SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
└── SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
4 directories, 1 file
drop sp_rsync a ok
(recording state in git...)
--------- after drop: ---------
../sp_rsync
0 directories, 0 files
Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
I'm tinkering with annex for about 1 week, "doing research" in preparation to use it as storage for backups.
Hmm, I guess this wasn't implemented because a generally small number of hash directories are not a bother. And because implementing it was a bit annoying.
Testremote cannot test for this, because remotes do not need to have the concept of a "directory". For example, a S3 bucket does not contain directories, only filenames that may contain a "/" in them. Also, I don't think it's necessarily a bug for a special remote to leave hash directories in place when removing files. There could be good reasons to do that in some cases.