![](https://seccdn.libravatar.org/avatar/cabdbf4d350ab6a15265803acab1634d.jpg?s=120&d=mm&r=g)
On 12/01/18 11:25 AM, David T-G wrote:
Anton --
...and then Anton Aylward said... % % On 11/01/18 06:30 PM, Carlos E. R. wrote: % >> % >> The best I can think of is to have a dummy directory that has symlinks to the % >> files generated by FIND. It seems a bit of a kludge. I'm certainly not happy % >> about the 'tree'. % % > Rather hardlinks, or the software would have to "follow" the links. % % Since the dummy directory is on new (temporary, 'throw-away') partition and the % sources are from a variety of partitions, no, it has to be symlinks.
Wait ... Why would the scratch area have to be on a separate partition? Hard links take [almost] no space, so unless the volume is crazy full there should be room to create a working dir and throw in a zillion links.
Go back and read what I said as 'specification' In absolute terms, maybe you're right in that it doesn't have to be on a throwaway partition. Maybe it could be a directory under /tmp for example, that was deleted afterwards. I'm well aware that hard links are just an entry in the directory with an inode number of an existing file. But really! A symlink is a small file with the of the linked file. it's really not that much more. Unless you have FS with bigblocks. And, even so, many late model FS use tricks to deal with files of only a few bytes, perhaps storing the data in the inode space. Check you MAN pages. But if you go back you'll also see mention of scatter-gather. Hard links have to be on the same file system' symlinks can cross file systems. Yes, I could have a scratch hardlink directory for backup on each FS and then point K3B at *ALL* of them, but that gets to be a nightmare from the admin & list generation POV. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org