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
adding a long hardlink without _fs APIs #192
Comments
I'm hitting this in ostreedev/ostree-rs-ext#162 I'm willing to work on a PR here. But reading the code, one thing that strikes me as somewhat odd is that we have this "base interface" in But why do we not directly expose all the API methods like It seems weird to me how many of the
The inverse problem here is that the |
We should support appending long symlink targets, because this occurs in real world filesystems. In my case, RPM set up `.build-id` symlinks which can get long. Add an `append_link()` method following the precendent of `append_path()` - we're just supporting *two* potentially long filenames. As a side benefit, we can just do the `std::io::empty()` dance internally and not require the caller to specify it. The addition of special case `append()` methods is unfortunate, because the header API methods are then really an attractive nuisance. We should potentially consider deprecating them. Closes: alexcrichton#192
PR in #273 |
We should support appending long symlink targets, because this occurs in real world filesystems. In my case, RPM set up `.build-id` symlinks which can get long. Add an `append_link()` method following the precendent of `append_path()` - we're just supporting *two* potentially long filenames. As a side benefit, we can just do the `std::io::empty()` dance internally and not require the caller to specify it. The addition of special case `append()` methods is unfortunate, because the header API methods are then really an attractive nuisance. We should potentially consider deprecating them. Closes: alexcrichton#192
(Regarding my confusion around |
We should support appending long symlink targets, because this occurs in real world filesystems. In my case, RPM set up `.build-id` symlinks which can get long. Add an `append_link()` method following the precendent of `append_path()` - we're just supporting *two* potentially long filenames. As a side benefit, we can just do the `std::io::empty()` dance internally and not require the caller to specify it. The addition of special case `append()` methods is unfortunate, because the header API methods are then really an attractive nuisance. We should potentially consider deprecating them. Closes: alexcrichton#192
We should support appending long symlink targets, because this occurs in real world filesystems. In my case, RPM set up `.build-id` symlinks which can get long. Add an `append_link()` method following the precendent of `append_path()` - we're just supporting *two* potentially long filenames. As a side benefit, we can just do the `std::io::empty()` dance internally and not require the caller to specify it. The addition of special case `append()` methods is unfortunate, because the header API methods are then really an attractive nuisance. We should potentially consider deprecating them. Closes: #192
Similar to #108, the internal helper method for appending long links is only accessible through APIs that attempt to access the filesystem.
It would be great if it were possible to pass a header (with symlink or hardlink
entry_type
) and aname
+link_name
asPath
and have the builder insert the necessary long-name headers. I.e. an equivalent toappend_data
Maybe some general intermediate-level API is missing for adding headers and data separately to orthogonalize the construction of complicated headers that must be written in several parts (long name, long links, sparse header) and their associated data chunks. A single function taking several enums to cover all those combinations might work too.
The text was updated successfully, but these errors were encountered: