Symlink & File Permission Support?

[coolaj86]

It appears that the default behavior is to strip the Mode and file permission bits and to read symlink targets rather than to save the path as the contents.

I suppose this could be circumvented by first running tar and then running vfsgen, or running some other process to save the metadata and zipping it together later.

I couldn't find any issues or docs about either symlinks or file permissions.

Is this explicitly not a goal of the project? Or just an oversight?

Why?

I'm working on a project that has an init subcommand which generates project files, including a .env.

# initializes .env and the ./scripts/ directory
gitdeploy init

# run with the default configuration
gitdeploy run

[dmitshur]

I couldn't find any issues or docs about either symlinks or file permissions.

Is this explicitly not a goal of the project? Or just an oversight?

This is a good question, thanks for asking.

I've never run into a need for preserving custom file permissions (beyond the directory vs file distinction), and so I didn't implement it.

I also prefer to keep this project as simple and portable as possible. Symlinks and file permissions are not the most portable concepts: some OSes support them one way, others in another way, and some not at all. A virtual filesystem generated on one OS should be usable by a program running on another OS.

I suspect preserving file mode is doable, as it's just an uint32. But it's worth thinking about carefully if it should be done, and if there should be any restrictions on allowed values.

I'm less sure about what it would mean to support symlinks. Go's upcoming support for embedded files won't support it either.