Feature request: Confirm mounting of remote locations or automount
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 20/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Área
- operating-systems
Línea de trabajo
El issue no nombra archivos, pruebas ni puntos de entrada. Empieza por describir cómo Timeshift selecciona y verifica las ubicaciones de los snapshots y, después, investiga las alternativas propuestas de automontaje remoto y de un marcador de carpeta de montaje vacía. Para darlo por terminado, será necesario acordar un enfoque para las ubicaciones remotas no disponibles, un comportamiento de montaje seguro y la notificación de fallos.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
I've been setting up to backup to a remote location rather than keep timeshift data locally. The main headache is if that remote location isn't available for some reason, in which case the timeshift data winds up dumping to the empty mount folder, using up space on the local drive for no good reason.
Ideally, timeshift really needs to integrate remote access just like gui file shares, being able to save to something like: smb://[email protected]/backup/this_machine and have timeshift automount to a temporary folder and unmount when it's done, sending a notification if something fails. This wouldn't be trivial, unfortunately.
You could workaround by placing a marker file in the empty mount folder telling timeshift to halt and notify there was an error if this file was found. The file would be hidden by the remote location whenever it was properly mounted. This would be a bit annoying to put in place and would require more knowledge of how mounting remote locations works.
- Lenguaje dominante
- Vala
- Estrellas
- 4.3k
- Forks
- 159
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de linuxmint/timeshift
-
Dificultad 1/5 1-3 horas Aptitud para principiantes 78/100
-
License parsing with GitHubAbierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 68/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 56/100
-
Dificultad 3/5 Medio día Aptitud para principiantes 63/100
-
Dificultad 3/5 1-2 días Aptitud para principiantes 50/100
Todos los issues de linuxmint/timeshift
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
aquasecurity/libbpfgo#560 ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100
nicobailon/pi-intercom#186 ·
Los mantenedores suelen responder en 1 día
-
arm follow-up signals
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
carrick-sh/carrick#921 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
leanprover/lean4#15982 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día