Symlinking a file into a tag directory should tag it

[Similacrest]

% ln -s file ~/tmsuroot/tags/test
ln: failed to create symbolic link '/home/sharedvi/tmsuroot/tags/test/file': Function not implemented

What I want:

% ln -s file ~/tmsuroot/tags/test
% tmsu files test
./file

Would simplify GUI tagging, for example.

[oniony]

I've looked at this before. The problem is you would have to give it a unique name. TMSU uses identifiers within the VFS directories to ensure uniqueness, so that if you tag two files with the same name with the same tag, they can both be shown in the tag directory.

Now if you're symlinking, you're going to have to somehow know the identifier up front. I've tried, in the past, allowing symlinking without the identifier and have TMSU assign it but it creates errors if TMSU changes the name during the symlinking operation.

The only other option i can think of would be for TMSU to drop the identifiers but that would cause errors as soon as you have a duplicate filename.

If you have any suggestions on how to handle this then I'd be happy to hear them. On 25 Apr 2016 08:56, "ShareDVI" [email protected] wrote:

% ln -s file ~/tmsuroot/tags/test ln: failed to create symbolic link '/home/sharedvi/tmsuroot/tags/test/file': Function not implemented

What I want:

% ln -s file ~/tmsuroot/tags/test % tmsu files ./test

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/oniony/TMSU/issues/69

[oniony]

See also original post.

On reflection maybe the option of specifying a zero is workable. I think I'll have another stab at this and see how it flies.

[0ion9]

@oniony : You write in point 2 of 'original post' link:

Either way, the meaning of zero will change over time (as new files are added) which could potentially break anything that is relying upon the filename (e.g. a graphical file manager that's been left open).

I'm guessing you reconsidered that evaluation? Personally -- assuming I understand the scenario correctly (link is created with number zero and is renamed to first available nonzero ID at TMSU's next opportunity) -- I would say that is entirely the file manager's responsibility to cope with, as renaming a symlink is a pretty ordinary operation. They are obligated to cope with much hairier things than that.

It does make me think about how you find out the final filename assigned within the VFS to your file in that tag directory. I guess it would mean that any scripted interaction would have to store a 'before' list of files, then compare that to the 'after' list to determine what file it ultimately created.

[oniony]

assuming I understand the scenario correctly (link is created with number zero and is renamed to first available nonzero ID at TMSU's next opportunity)

Yes, but if it happens immediately, this can confuse the file manager that created the file when it checks that the link was created successfully (by using 'stat'/'lstat'). I hit this problem when I looked at this issue previously: I used a graphical program to create the link, TMSU assigned it an ID but then the program attempted to 'stat' the file with the zero identifier and TMSU told it the file did not exist. I did consider adding a grace period of a second or so after each file creation, or even until the next file is created, but then my complexity alarm went off and I left it for another day.

[oniony]

Anyhow, I'll give this another shot soon: I'm sure I could get the VFS to respond affirmatively with the zero ID name for a second or two after creation, which would allow the link creation to succeed.