git-annex/doc/todo/dumb__44___unsafe__44___human-readable_backend.mdwn

This was already discussed twice previously: [[forum/original_filename_on_s3/]] and [[todo/Facilitate_public_pretty_S3_URLs/]]. Yet I am still constantly having problems with this when trying to use git-annex to do some particular stuff.

My latest example is a friend that wanted to sync files to a remote Webdav server. While I know he can use [[special_remotes/webdav/]] support, the resulting filenames on the webdav server will be basically garbled beyond recognition for any user that will use the Webdav server without git-annex.

I understand the rationale behind the existing [[backends]], but wouldn't it be possible to implement a new backend that would just use the filename as a key?

I know this would have several downsides:

* lack of deduplication
* much more exposed to corruption (no checksum to check against recorded? or can this be put somewhere else?)

The main advantage, for me, is much better interoperability: any remote becomes usable by other non-git-annex clients... It would also be great as it would allow me to store only a *part* of my git-annex files on a remote without having a forest of empty files (on broken filesystems) or symlinks (on real filesystems) for files that are missing, something that is a massive source of confusion for users I work with. It could, for example, allow me to create thumb drives that would solve the [[hide missing files]] problem. -- [[anarcat]]

> [[done]]; the new `git-annex export` feature allows you to export a tree
> to a special remote. --[[Joey]]

> > That is not exactly what I was hoping for. It's a little confusing to have a whole other command set for remotes. For example, I stumbled upon a [[bug in the webdav special remote|bugs/cannot_talk_with_nextcloud_server]] which I could work around by using the rclone remote, *except* that remote still doesn't support exporttree, because it's so special. If this would have been implemented through a "dumb" backend the way I proposed, all those special remotes would have worked out of the box without needing to be individually ported. Now I can't use this feature on my WebDAV server because of that bug...
> > 
> > I also need to learn yet another command in an already crowded namespace. This makes it harder for new people to get familiar with git-annex.
> >
> > I nevertheless thank you for the new feature and hope to use it to publish shiny clean files in remotes in the future! :) -- [[anarcat]]
another idea 2016-02-01 19:53:04 +00:00			`This was already discussed twice previously: [[forum/original_filename_on_s3/]] and [[todo/Facilitate_public_pretty_S3_URLs/]]. Yet I am still constantly having problems with this when trying to use git-annex to do some particular stuff.`

			`My latest example is a friend that wanted to sync files to a remote Webdav server. While I know he can use [[special_remotes/webdav/]] support, the resulting filenames on the webdav server will be basically garbled beyond recognition for any user that will use the Webdav server without git-annex.`

			`I understand the rationale behind the existing [[backends]], but wouldn't it be possible to implement a new backend that would just use the filename as a key?`

			`I know this would have several downsides:`

			`* lack of deduplication`
			`* much more exposed to corruption (no checksum to check against recorded? or can this be put somewhere else?)`

			The main advantage, for me, is much better interoperability: any remote becomes usable by other non-git-annex clients... It would also be great as it would allow me to store only a part of my git-annex files on a remote without having a forest of empty files (on broken filesystems) or symlinks (on real filesystems) for files that are missing, something that is a massive source of confusion for users I work with. It could, for example, allow me to create thumb drives that would solve the [[hide missing files]] problem. -- [[anarcat]]
mention git-annex export 2017-09-07 20:17:46 +00:00
			> [[done]]; the new `git-annex export` feature allows you to export a tree
			`> to a special remote. --[[Joey]]`
notes 2018-10-07 18:16:13 +00:00
			> > That is not exactly what I was hoping for. It's a little confusing to have a whole other command set for remotes. For example, I stumbled upon a [[bug in the webdav special remote\|bugs/cannot_talk_with_nextcloud_server]] which I could work around by using the rclone remote, except that remote still doesn't support exporttree, because it's so special. If this would have been implemented through a "dumb" backend the way I proposed, all those special remotes would have worked out of the box without needing to be individually ported. Now I can't use this feature on my WebDAV server because of that bug...
			`> >`
			`> > I also need to learn yet another command in an already crowded namespace. This makes it harder for new people to get familiar with git-annex.`
			`> >`
			`> > I nevertheless thank you for the new feature and hope to use it to publish shiny clean files in remotes in the future! :) -- [[anarcat]]`