Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Android rsync probleem
5 views
Skip to first unread message
Cecil Westerhof
Mar 15, 2023, 9:44:04 AM3/15/23
to
I heb een Lenova Android tablet.
Wanneer ik die mount in nemo zie ik:
mtp://LENOVO_Lenovo_TB-8705F_HA141AZC/
Op de command-line moet ik dan naar:
/run/user/1000/gvfs/mtp:host=LENOVO_Lenovo_TB-8705F_HA141AZC/
Wanneer ik naar de Andoid directory ga, dan kan ik zonder problemen
doen:
rsync -avuP Documents/ ~/Documents/Lenova/Documents/
Als ik dan op de Linux directory iets aanpas en dan doe:
rsync -avuP ~/Documents/Lenova/Documents/ Documents/
Dan krijg ik:
rsync: [receiver] mkstemp
"/run/user/1000/gvfs/mtp:host=LENOVO_Lenovo_TB-8705F_HA141AZC/Internal
shared storage/Documents/.todo.txt.DWQONE" failed: Operation not
supported (95)
en:
rsync error: some files/attrs were not transferred (see previous
errors) (code 23) at main.c(1333) [sender=3.2.3]
Wat kan hier aan de hand zijn?
Dit is op Debian 11 met:
rsync version 3.2.3 protocol version 31
--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
Wanneer ik die mount in nemo zie ik:
mtp://LENOVO_Lenovo_TB-8705F_HA141AZC/
Op de command-line moet ik dan naar:
/run/user/1000/gvfs/mtp:host=LENOVO_Lenovo_TB-8705F_HA141AZC/
Wanneer ik naar de Andoid directory ga, dan kan ik zonder problemen
doen:
rsync -avuP Documents/ ~/Documents/Lenova/Documents/
Als ik dan op de Linux directory iets aanpas en dan doe:
rsync -avuP ~/Documents/Lenova/Documents/ Documents/
Dan krijg ik:
rsync: [receiver] mkstemp
"/run/user/1000/gvfs/mtp:host=LENOVO_Lenovo_TB-8705F_HA141AZC/Internal
shared storage/Documents/.todo.txt.DWQONE" failed: Operation not
supported (95)
en:
rsync error: some files/attrs were not transferred (see previous
errors) (code 23) at main.c(1333) [sender=3.2.3]
Wat kan hier aan de hand zijn?
Dit is op Debian 11 met:
rsync version 3.2.3 protocol version 31
--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
Oscar
Mar 21, 2023, 5:37:08 AM3/21/23
to
In article <87cz5aq...@munus.decebal.nl>,
Wat is nemo voor een ding?
>Dan krijg ik:
> rsync: [receiver] mkstemp
>"/run/user/1000/gvfs/mtp:host=LENOVO_Lenovo_TB-8705F_HA141AZC/Internal
>shared storage/Documents/.todo.txt.DWQONE" failed: Operation not
>supported (95)
Rsync heeft hier moeite met het creeren van .todo.txt.DWQONE in de
directory storage/Documents omdat deze bewerking niet ondersteund wordt
door het onderliggende filesystem...
> rsync error: some files/attrs were not transferred (see previous
>errors) (code 23) at main.c(1333) [sender=3.2.3]
... en daarom kon rsync een of meer bestanden of eigenschappen daarvan
niet overbrengen.
>Wat kan hier aan de hand zijn?
Van alles. Komt de file wel aan? Dan kan het een onschuldige melding
zijn dat bepaalde attributen niet overgenomen konden worden. Je zou eens
kunnen kijken wat mkstemp precies doet. Is dat een secure mktemp of zo?
Het kan ook zijn dat het fs uberhaupt geen schrijfacties ondersteunt.
Dat is simpel te controleren door zelf iets proberen te schrijven.
De derde mogelijkheid is dat het FS niet overweg kan met de naam. Ook
dat kan je testen als je wel kan schrijven.
Sowieso is het wel nuttig om te weten dat rsync tijdens de transfer een
tijdelijke filename gebruikt. Hier probeer je "todo.txt" te syncen. Daar
zet rsync een punt voor en plakt er nog een random string achteraan. Of
eigenlijk, rsync gebruikt zo te zien de call 'mkstemp' om dat voor hem
te doen. Als de transfer lukt, dan volgt een mv naar de originele naam.
Wordt de transfer afgebroken, maar heeft rsync nog wel een verbinding,
dan wordt ie gedelete. In het ergste geval vind je later dit tijdelijke
bestand terug in je directory, maar dan weet je nu dat het een restant
is van een mislukte rsync.
--
[J|O|R] <- .signature.gz
Wat is nemo voor een ding?
>Dan krijg ik:
> rsync: [receiver] mkstemp
>"/run/user/1000/gvfs/mtp:host=LENOVO_Lenovo_TB-8705F_HA141AZC/Internal
>shared storage/Documents/.todo.txt.DWQONE" failed: Operation not
>supported (95)
directory storage/Documents omdat deze bewerking niet ondersteund wordt
door het onderliggende filesystem...
> rsync error: some files/attrs were not transferred (see previous
>errors) (code 23) at main.c(1333) [sender=3.2.3]
niet overbrengen.
>Wat kan hier aan de hand zijn?
zijn dat bepaalde attributen niet overgenomen konden worden. Je zou eens
kunnen kijken wat mkstemp precies doet. Is dat een secure mktemp of zo?
Het kan ook zijn dat het fs uberhaupt geen schrijfacties ondersteunt.
Dat is simpel te controleren door zelf iets proberen te schrijven.
De derde mogelijkheid is dat het FS niet overweg kan met de naam. Ook
dat kan je testen als je wel kan schrijven.
Sowieso is het wel nuttig om te weten dat rsync tijdens de transfer een
tijdelijke filename gebruikt. Hier probeer je "todo.txt" te syncen. Daar
zet rsync een punt voor en plakt er nog een random string achteraan. Of
eigenlijk, rsync gebruikt zo te zien de call 'mkstemp' om dat voor hem
te doen. Als de transfer lukt, dan volgt een mv naar de originele naam.
Wordt de transfer afgebroken, maar heeft rsync nog wel een verbinding,
dan wordt ie gedelete. In het ergste geval vind je later dit tijdelijke
bestand terug in je directory, maar dan weet je nu dat het een restant
is van een mislukte rsync.
--
[J|O|R] <- .signature.gz
Cecil Westerhof
Mar 24, 2023, 4:14:15 AM3/24/23
to
jornws...@xs4all.nl (Oscar) writes:
> In article <87cz5aq...@munus.decebal.nl>,
> Cecil Westerhof <Ce...@decebal.nl> wrote:
>>Wanneer ik die mount in nemo zie ik:
>
> Wat is nemo voor een ding?
Een file manager die ik in xfce4 gebruik omdat thunar een aantal
> In article <87cz5aq...@munus.decebal.nl>,
> Cecil Westerhof <Ce...@decebal.nl> wrote:
>>Wanneer ik die mount in nemo zie ik:
>
> Wat is nemo voor een ding?
'problemen' geeft.
https://en.wikipedia.org/wiki/Nemo_(file_manager)
>>Dan krijg ik:
>> rsync: [receiver] mkstemp
>>"/run/user/1000/gvfs/mtp:host=LENOVO_Lenovo_TB-8705F_HA141AZC/Internal
>>shared storage/Documents/.todo.txt.DWQONE" failed: Operation not
>>supported (95)
>
> Rsync heeft hier moeite met het creeren van .todo.txt.DWQONE in de
> directory storage/Documents omdat deze bewerking niet ondersteund wordt
> door het onderliggende filesystem...
-rw------- 1 cecil cecil 0 Mar 15 12:26 .todo.txt.DWQONE
>> rsync error: some files/attrs were not transferred (see previous
>>errors) (code 23) at main.c(1333) [sender=3.2.3]
>
> ... en daarom kon rsync een of meer bestanden of eigenschappen daarvan
> niet overbrengen.
bewerkingen niet kunnen worden gedaan?
>>Wat kan hier aan de hand zijn?
>
> Van alles. Komt de file wel aan? Dan kan het een onschuldige melding
> zijn dat bepaalde attributen niet overgenomen konden worden. Je zou eens
> kunnen kijken wat mkstemp precies doet. Is dat een secure mktemp of zo?
bestanden die moet worden gesynchroniseerd er wel is, gaat het fout.
> Het kan ook zijn dat het fs uberhaupt geen schrijfacties ondersteunt.
> Dat is simpel te controleren door zelf iets proberen te schrijven.
Echter als er een todo.txt staat, dan gaat het fout.
> De derde mogelijkheid is dat het FS niet overweg kan met de naam. Ook
> dat kan je testen als je wel kan schrijven.
> Sowieso is het wel nuttig om te weten dat rsync tijdens de transfer een
> tijdelijke filename gebruikt. Hier probeer je "todo.txt" te syncen. Daar
> zet rsync een punt voor en plakt er nog een random string achteraan. Of
> eigenlijk, rsync gebruikt zo te zien de call 'mkstemp' om dat voor hem
> te doen. Als de transfer lukt, dan volgt een mv naar de originele naam.
> Wordt de transfer afgebroken, maar heeft rsync nog wel een verbinding,
> dan wordt ie gedelete. In het ergste geval vind je later dit tijdelijke
> bestand terug in je directory, maar dan weet je nu dat het een restant
> is van een mislukte rsync.
Maar er gebeurd iets vreemds. Als ik op mijn Linux commandline geef:
touch dummy
Dan krijg ik:
touch: setting times of 'dummy': Operation not supported
Maar dummy is wel aangemaakt:
-rw------- 1 cecil cecil 0 Mar 24 09:00 dummy
Een 'rm dummy' werkt zonder problemen. Een 'touch dummy' geeft
dezelfde melding en $? bevat dan 1. En dummy is gewoon aangemaakt.
Als ik geef:
mv todo.txt todo2.txt
Dan krijg ik:
mv: cannot move 'todo.txt' to 'todo2.txt': Input/output error
Dan bevat $? ook 1 en in dit geval is de mv ook daadwerkelijk niet
uitgevoerd.
Het bijzondere is dat ik in de file manager todo.txt wel kan hernoemen
naar todo2.txt.
Voor als het van belang is, mount geeft:
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
Oscar
Mar 30, 2023, 5:11:31 AM3/30/23
to
[Crosspost naar nl.comp.os.linux.techniek]
In article <87sfdum...@munus.decebal.nl>,
ondersteuning of maakt die gewoon gebruik van de onderliggende mount van
het systeem, waar jij met rsync tegenaan praat?
>>>Dan krijg ik:
>>> rsync: [receiver] mkstemp
>>>"/run/user/1000/gvfs/mtp:host=LENOVO_Lenovo_TB-8705F_HA141AZC/Internal
>>>shared storage/Documents/.todo.txt.DWQONE" failed: Operation not
>>>supported (95)
>>
>> Rsync heeft hier moeite met het creeren van .todo.txt.DWQONE in de
>> directory storage/Documents omdat deze bewerking niet ondersteund wordt
>> door het onderliggende filesystem...
>
>Vreemd: ik zie dat bestand met een grote van 0 bytes daar staan.
> -rw------- 1 cecil cecil 0 Mar 15 12:26 .todo.txt.DWQONE
Niet zo vreemd. Blijkbaar kon mkstemp de file wel aanmaken, maar ging
het bij een volgende stap verkeerd. Nuttige informatie.
>>> rsync error: some files/attrs were not transferred (see previous
>>>errors) (code 23) at main.c(1333) [sender=3.2.3]
>>
>> ... en daarom kon rsync een of meer bestanden of eigenschappen daarvan
>> niet overbrengen.
>
>Kan het zijn dat het bestand wel kan worden aangemaakt, maar dat de
>bewerkingen niet kunnen worden gedaan?
Check. Jammer dat je niet laat zien hoe de originele todo.txt er uit
ziet, maar als die verschilt van 'mode 600, cecil:cecil' dan zal rsync
dat proberen aan te passen. Je gaf immers '-a/--archive' mee als
parameter.
>>>Wat kan hier aan de hand zijn?
>>
>> Van alles. Komt de file wel aan? Dan kan het een onschuldige melding
>> zijn dat bepaalde attributen niet overgenomen konden worden. Je zou eens
>> kunnen kijken wat mkstemp precies doet. Is dat een secure mktemp of zo?
>
>Als er geen bestanden zijn gaat alles goed, maar zodra een van de
>bestanden die moet worden gesynchroniseerd er wel is, gaat het fout.
Uit man rsync(1):
-a, --archive archive mode; equals -rlptgoD (no -H,-A,-X)
Je kan -a vervangen door -rlptgoD en dan een voor een letters er af
halen tot het werkt. Of eerst proberen met alleen -r/--recursive en
letters toevoegen tot het niet meer werkt.
Ik ben eigenlijk wel benieuwd of alleen -r al wel resultaat geeft?
>> Het kan ook zijn dat het fs uberhaupt geen schrijfacties ondersteunt.
>> Dat is simpel te controleren door zelf iets proberen te schrijven.
>
>Dat is het dus niet, wanneer er geen bestanden zijn, gaat alles goed.
>Echter als er een todo.txt staat, dan gaat het fout.
>
>
>> De derde mogelijkheid is dat het FS niet overweg kan met de naam. Ook
>> dat kan je testen als je wel kan schrijven.
>
>Dat is het dus niet, want het bestand staat er gewoon.
Check. Dat was dan ook nuttige info.
>> Sowieso is het wel nuttig om te weten dat rsync tijdens de transfer een
>> tijdelijke filename gebruikt. Hier probeer je "todo.txt" te syncen. Daar
>> zet rsync een punt voor en plakt er nog een random string achteraan. Of
>> eigenlijk, rsync gebruikt zo te zien de call 'mkstemp' om dat voor hem
>> te doen. Als de transfer lukt, dan volgt een mv naar de originele naam.
>> Wordt de transfer afgebroken, maar heeft rsync nog wel een verbinding,
>> dan wordt ie gedelete. In het ergste geval vind je later dit tijdelijke
>> bestand terug in je directory, maar dan weet je nu dat het een restant
>> is van een mislukte rsync.
>
>Dat is dus wat er gebeurd.
Niet heel netjes van rsync. Eigenlijk zou hij dat mislukte tijdelijke
bestand weer op moeten ruimen, maar misschien kan dat niet. Als de call
'mkstemp()' alleen maar doorgeeft dat er iets fout ging, zonder aan te
geven of er misschien al een file was aangemaakt, kan rsync ook niet
weten wat er opgeruimd moet worden.
Dit zou wel eens tot verhitte discussies tussen de developers kunnen
leiden. Wie is er in zo'n geval verantwoordelijk voor het opruimen van
het tijdelijke bestand, en waarom?
Dat het bestand nog bestaat, is wel handig bij het troubleshooten. Maar
net als 'finder droppings' is het naar de gebruiker toe onverwachte
vervuiling van het filesystem.
>Maar er gebeurd iets vreemds. Als ik op mijn Linux commandline geef:
> touch dummy
>
>Dan krijg ik:
> touch: setting times of 'dummy': Operation not supported
Hmm.. Het is duidelijk geen volledige implementatie van een filesystem.
Als jij -a tegen rsync zegt, wil hij alle attributen van de file
meenemen naar de overkant. Als het filesystem al niet overweg kan met
het aanpassen van de tijden, dan zal die ook wel niet veel kunnen met
ingewikkeldere dingen, zoals unix permissies.
>Maar dummy is wel aangemaakt:
> -rw------- 1 cecil cecil 0 Mar 24 09:00 dummy
Stap 0: touch kijkt op de klok. Dat lukt.
Stap 1: touch ziet dat de file nog niet bestaat.
Stap 2: touch maakt de nieuwe file. Dat lukt.
Stap 3: touch wil de tijd aanpassen naar die van Stap 0. Mislukt.
Nu blijf jij achter met een foutmelding en een file die wel bestaat,
maar nog niet de tijd heeft die je wou. Of in dit geval eigenlijk wel,
maar touch kan in principe ook andere tijden aan een file geven. Ik kan
me dus voorstellen dat de "tijd om te geven" wordt bepaald tijdens het
lezen van de argumenten, ook al is in dit geval de default tijd goed
genoeg.
>Een 'rm dummy' werkt zonder problemen. Een 'touch dummy' geeft
>dezelfde melding en $? bevat dan 1. En dummy is gewoon aangemaakt.
Verklaarbaar als touch inderdaad volgens die stappen werkt. De
foutmelding is immers "ik kon de tijden van de file niet aanpassen!"
>
>Als ik geef:
> mv todo.txt todo2.txt
>
>Dan krijg ik:
> mv: cannot move 'todo.txt' to 'todo2.txt': Input/output error
>
>Dan bevat $? ook 1 en in dit geval is de mv ook daadwerkelijk niet
>uitgevoerd.
Jemig, kan dat filesystem ook al niet renamen? Een mv binnen dezelfde
mount wordt immers uitgevoerd met de rename(2) systemcall.
Zijstapje omdat vrijwel niemand dat tegenwoordig nog weet: Als je een
getalletje tussen haakjes achter een naampje ziet staan, dan is dat het
hoofdstuk in de manpages waar je meer info kan vinden.
Doe je 'man rename' dan krijg je mogelijk de man-page van het commando
'rename' uit hoofdstuk 1 (user commands) als je toevallig het pakketje
rename hebt geinstalleerd. Je kan man vragen om in hoofdstuk 2 (system
calls) te kijken met: 'man 2 rename'. Op dezelfde manier heb je 'man 2
mount' en 'man 8 mount'. De ene voor de systemcall, de andere voor het
admin commando.
Met 'man -wa naampje' kun je zien welke manual pages met naampje je
allemaal geinstalleerd hebt. Met 'manpages-dev' geinstalleerd, krijg je
bijvoorbeeld zoiets:
oscar@linux:~$ man -wa mount | xargs dpkg -S
mount: /usr/share/man/man8/mount.8.gz
manpages-dev: /usr/share/man/man2/mount.2.gz
Maar ik dwaal af...
>Het bijzondere is dat ik in de file manager todo.txt wel kan hernoemen
>naar todo2.txt.
Het kan zijn dat die onzichtbaar twee pogingen doet:
result = rename(oldname, newname);
if(!result) {
// oh jammer, toch niet dezelfde partitie
result = copy(oldname, newname);
if(result) unlink(oldname);
}
Ik heb het op mijn mac wel eens als ik een samba share mount, waar op de
onderliggende linux-machine weer verschillende mountpoints heb hangen.
Vanaf de mac gezien lijkt dat 1 filesystem, maar als ik iets wil moven
van de ene plek naar de andere, dan geeft de server een error op het
rename() commando. Daar snapt 'mv' dan helemaal niks van, dus die geeft
mij weer een foutmelding, terwijl die terug zou moeten vallen naar
copy&delete.
Nou heb jij daar een filesystem dat de rename() call niet
geimplementeerd heeft, waar mv net zo goed van in de war raakt.
>Voor als het van belang is, mount geeft:
> gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
Ziet er inderdaad uit als een handjevol code onder het fuse-systeem van
linux. Ik heb daar laatst ook wat mee lopen spelen om te snappen wat er
fout gaat op een produktiesysteem op mijn werk. De kernel biedt daar een
interface tussen wat code dat in user-space draait en programma's die
denken dat ze een echt filesytem benaderen. Je kan zoveel calls
implementeren als je wil en teruggeven wat je wil, als het maar in de
API past. Bij mijn experimentje kon je alleen ls en cat doen. Met ls zag
je een file. Met 'cat diefile' zag je wat tekst. Alle andere handelingen
gaven een foutmelding omdat ik ze niet geimplementeerd had.
Jouw Android-koppel-appje biedt je net genoeg om bestanden van en naar
je toestel te kopieren en verder moet je er gewoon niet al te veel van
verwachten.
TL;DR: probeer eens rsync -rv ... ipv rscync -av ...
In article <87sfdum...@munus.decebal.nl>,
Cecil Westerhof <Ce...@decebal.nl> wrote:
>jornws...@xs4all.nl (Oscar) writes:
>
>> In article <87cz5aq...@munus.decebal.nl>,
>> Cecil Westerhof <Ce...@decebal.nl> wrote:
>>>Wanneer ik die mount in nemo zie ik:
>>
>> Wat is nemo voor een ding?
>
>Een file manager die ik in xfce4 gebruik omdat thunar een aantal
>'problemen' geeft.
> https://en.wikipedia.org/wiki/Nemo_(file_manager)
Oh, ken ik allemaal niet zo. Maar heeft nemo zijn eigen Android
>jornws...@xs4all.nl (Oscar) writes:
>
>> In article <87cz5aq...@munus.decebal.nl>,
>> Cecil Westerhof <Ce...@decebal.nl> wrote:
>>>Wanneer ik die mount in nemo zie ik:
>>
>> Wat is nemo voor een ding?
>
>Een file manager die ik in xfce4 gebruik omdat thunar een aantal
>'problemen' geeft.
> https://en.wikipedia.org/wiki/Nemo_(file_manager)
ondersteuning of maakt die gewoon gebruik van de onderliggende mount van
het systeem, waar jij met rsync tegenaan praat?
>>>Dan krijg ik:
>>> rsync: [receiver] mkstemp
>>>"/run/user/1000/gvfs/mtp:host=LENOVO_Lenovo_TB-8705F_HA141AZC/Internal
>>>shared storage/Documents/.todo.txt.DWQONE" failed: Operation not
>>>supported (95)
>>
>> Rsync heeft hier moeite met het creeren van .todo.txt.DWQONE in de
>> directory storage/Documents omdat deze bewerking niet ondersteund wordt
>> door het onderliggende filesystem...
>
>Vreemd: ik zie dat bestand met een grote van 0 bytes daar staan.
> -rw------- 1 cecil cecil 0 Mar 15 12:26 .todo.txt.DWQONE
het bij een volgende stap verkeerd. Nuttige informatie.
>>> rsync error: some files/attrs were not transferred (see previous
>>>errors) (code 23) at main.c(1333) [sender=3.2.3]
>>
>> ... en daarom kon rsync een of meer bestanden of eigenschappen daarvan
>> niet overbrengen.
>
>Kan het zijn dat het bestand wel kan worden aangemaakt, maar dat de
>bewerkingen niet kunnen worden gedaan?
ziet, maar als die verschilt van 'mode 600, cecil:cecil' dan zal rsync
dat proberen aan te passen. Je gaf immers '-a/--archive' mee als
parameter.
>>>Wat kan hier aan de hand zijn?
>>
>> Van alles. Komt de file wel aan? Dan kan het een onschuldige melding
>> zijn dat bepaalde attributen niet overgenomen konden worden. Je zou eens
>> kunnen kijken wat mkstemp precies doet. Is dat een secure mktemp of zo?
>
>Als er geen bestanden zijn gaat alles goed, maar zodra een van de
>bestanden die moet worden gesynchroniseerd er wel is, gaat het fout.
-a, --archive archive mode; equals -rlptgoD (no -H,-A,-X)
Je kan -a vervangen door -rlptgoD en dan een voor een letters er af
halen tot het werkt. Of eerst proberen met alleen -r/--recursive en
letters toevoegen tot het niet meer werkt.
Ik ben eigenlijk wel benieuwd of alleen -r al wel resultaat geeft?
>> Het kan ook zijn dat het fs uberhaupt geen schrijfacties ondersteunt.
>> Dat is simpel te controleren door zelf iets proberen te schrijven.
>
>Dat is het dus niet, wanneer er geen bestanden zijn, gaat alles goed.
>Echter als er een todo.txt staat, dan gaat het fout.
>
>
>> De derde mogelijkheid is dat het FS niet overweg kan met de naam. Ook
>> dat kan je testen als je wel kan schrijven.
>
>Dat is het dus niet, want het bestand staat er gewoon.
>> Sowieso is het wel nuttig om te weten dat rsync tijdens de transfer een
>> tijdelijke filename gebruikt. Hier probeer je "todo.txt" te syncen. Daar
>> zet rsync een punt voor en plakt er nog een random string achteraan. Of
>> eigenlijk, rsync gebruikt zo te zien de call 'mkstemp' om dat voor hem
>> te doen. Als de transfer lukt, dan volgt een mv naar de originele naam.
>> Wordt de transfer afgebroken, maar heeft rsync nog wel een verbinding,
>> dan wordt ie gedelete. In het ergste geval vind je later dit tijdelijke
>> bestand terug in je directory, maar dan weet je nu dat het een restant
>> is van een mislukte rsync.
>
>Dat is dus wat er gebeurd.
bestand weer op moeten ruimen, maar misschien kan dat niet. Als de call
'mkstemp()' alleen maar doorgeeft dat er iets fout ging, zonder aan te
geven of er misschien al een file was aangemaakt, kan rsync ook niet
weten wat er opgeruimd moet worden.
Dit zou wel eens tot verhitte discussies tussen de developers kunnen
leiden. Wie is er in zo'n geval verantwoordelijk voor het opruimen van
het tijdelijke bestand, en waarom?
Dat het bestand nog bestaat, is wel handig bij het troubleshooten. Maar
net als 'finder droppings' is het naar de gebruiker toe onverwachte
vervuiling van het filesystem.
>Maar er gebeurd iets vreemds. Als ik op mijn Linux commandline geef:
> touch dummy
>
>Dan krijg ik:
> touch: setting times of 'dummy': Operation not supported
Als jij -a tegen rsync zegt, wil hij alle attributen van de file
meenemen naar de overkant. Als het filesystem al niet overweg kan met
het aanpassen van de tijden, dan zal die ook wel niet veel kunnen met
ingewikkeldere dingen, zoals unix permissies.
>Maar dummy is wel aangemaakt:
> -rw------- 1 cecil cecil 0 Mar 24 09:00 dummy
Stap 1: touch ziet dat de file nog niet bestaat.
Stap 2: touch maakt de nieuwe file. Dat lukt.
Stap 3: touch wil de tijd aanpassen naar die van Stap 0. Mislukt.
Nu blijf jij achter met een foutmelding en een file die wel bestaat,
maar nog niet de tijd heeft die je wou. Of in dit geval eigenlijk wel,
maar touch kan in principe ook andere tijden aan een file geven. Ik kan
me dus voorstellen dat de "tijd om te geven" wordt bepaald tijdens het
lezen van de argumenten, ook al is in dit geval de default tijd goed
genoeg.
>Een 'rm dummy' werkt zonder problemen. Een 'touch dummy' geeft
>dezelfde melding en $? bevat dan 1. En dummy is gewoon aangemaakt.
foutmelding is immers "ik kon de tijden van de file niet aanpassen!"
>
>Als ik geef:
> mv todo.txt todo2.txt
>
>Dan krijg ik:
> mv: cannot move 'todo.txt' to 'todo2.txt': Input/output error
>
>Dan bevat $? ook 1 en in dit geval is de mv ook daadwerkelijk niet
>uitgevoerd.
mount wordt immers uitgevoerd met de rename(2) systemcall.
Zijstapje omdat vrijwel niemand dat tegenwoordig nog weet: Als je een
getalletje tussen haakjes achter een naampje ziet staan, dan is dat het
hoofdstuk in de manpages waar je meer info kan vinden.
Doe je 'man rename' dan krijg je mogelijk de man-page van het commando
'rename' uit hoofdstuk 1 (user commands) als je toevallig het pakketje
rename hebt geinstalleerd. Je kan man vragen om in hoofdstuk 2 (system
calls) te kijken met: 'man 2 rename'. Op dezelfde manier heb je 'man 2
mount' en 'man 8 mount'. De ene voor de systemcall, de andere voor het
admin commando.
Met 'man -wa naampje' kun je zien welke manual pages met naampje je
allemaal geinstalleerd hebt. Met 'manpages-dev' geinstalleerd, krijg je
bijvoorbeeld zoiets:
oscar@linux:~$ man -wa mount | xargs dpkg -S
mount: /usr/share/man/man8/mount.8.gz
manpages-dev: /usr/share/man/man2/mount.2.gz
Maar ik dwaal af...
>Het bijzondere is dat ik in de file manager todo.txt wel kan hernoemen
>naar todo2.txt.
result = rename(oldname, newname);
if(!result) {
// oh jammer, toch niet dezelfde partitie
result = copy(oldname, newname);
if(result) unlink(oldname);
}
Ik heb het op mijn mac wel eens als ik een samba share mount, waar op de
onderliggende linux-machine weer verschillende mountpoints heb hangen.
Vanaf de mac gezien lijkt dat 1 filesystem, maar als ik iets wil moven
van de ene plek naar de andere, dan geeft de server een error op het
rename() commando. Daar snapt 'mv' dan helemaal niks van, dus die geeft
mij weer een foutmelding, terwijl die terug zou moeten vallen naar
copy&delete.
Nou heb jij daar een filesystem dat de rename() call niet
geimplementeerd heeft, waar mv net zo goed van in de war raakt.
>Voor als het van belang is, mount geeft:
> gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
linux. Ik heb daar laatst ook wat mee lopen spelen om te snappen wat er
fout gaat op een produktiesysteem op mijn werk. De kernel biedt daar een
interface tussen wat code dat in user-space draait en programma's die
denken dat ze een echt filesytem benaderen. Je kan zoveel calls
implementeren als je wil en teruggeven wat je wil, als het maar in de
API past. Bij mijn experimentje kon je alleen ls en cat doen. Met ls zag
je een file. Met 'cat diefile' zag je wat tekst. Alle andere handelingen
gaven een foutmelding omdat ik ze niet geimplementeerd had.
Jouw Android-koppel-appje biedt je net genoeg om bestanden van en naar
je toestel te kopieren en verder moet je er gewoon niet al te veel van
verwachten.
TL;DR: probeer eens rsync -rv ... ipv rscync -av ...
Oscar
Mar 30, 2023, 5:20:12 AM3/30/23
to
In article <u03jo0$pofi$1...@dont-email.me>, Oscar <jornws...@xs4all.nl> wrote:
> result = rename(oldname, newname);
> if(!result) {
> // oh jammer, toch niet dezelfde partitie
> result = copy(oldname, newname);
> if(result) unlink(oldname);
> }
Misschien ten overvloede, maar: DO NOT RUN THIS AT HOME!
> result = rename(oldname, newname);
> if(!result) {
> // oh jammer, toch niet dezelfde partitie
> result = copy(oldname, newname);
> if(result) unlink(oldname);
> }
Dit lijkt misschien een beetje op werkende C-code, maar ik heb niet eens
de moeite genomen om op te zoeken hoe rename(2) ook alweer werkt, laat
staan of de error-checking goed werkt. Grote kans dat ik hem net
verkeerd om gebruik. Als result een foutcode is, dan is 0 juist goed.
Cecil Westerhof
Mar 30, 2023, 8:28:09 AM3/30/23
to
jornws...@xs4all.nl (Oscar) writes:
Ik ga het geheel eens doorwerken. Maar kan op een ding al wel antwoord
geven. (Denk ik.)
> [Crosspost naar nl.comp.os.linux.techniek]
>
> In article <87sfdum...@munus.decebal.nl>,
> Cecil Westerhof <Ce...@decebal.nl> wrote:
>>jornws...@xs4all.nl (Oscar) writes:
>>
>>> In article <87cz5aq...@munus.decebal.nl>,
>>> Cecil Westerhof <Ce...@decebal.nl> wrote:
>>>>Wanneer ik die mount in nemo zie ik:
>>>
>>> Wat is nemo voor een ding?
>>
>>Een file manager die ik in xfce4 gebruik omdat thunar een aantal
>>'problemen' geeft.
>> https://en.wikipedia.org/wiki/Nemo_(file_manager)
>
> Oh, ken ik allemaal niet zo. Maar heeft nemo zijn eigen Android
> ondersteuning of maakt die gewoon gebruik van de onderliggende mount van
> het systeem, waar jij met rsync tegenaan praat?
Volgens mij spreekt nemo gewoon met het file systeem, maar op een
andere manier dan rsync.
Nemo gebruikt:
mtp://LENOVO_Lenovo_TB-8705F_HA141AZC/
Terwijl rsync gebruikt:
/run/user/1000/gvfs/mtp:host=LENOVO_Lenovo_TB-8705F_HA141AZC/
Ik kan straks ook weleens kijken wat thunar gebruikt. Ik neem aan
hetzelfde als nemo, maar het kan geen kwaad om het te checken.
Ik ga het geheel eens doorwerken. Maar kan op een ding al wel antwoord
geven. (Denk ik.)
> [Crosspost naar nl.comp.os.linux.techniek]
>
> In article <87sfdum...@munus.decebal.nl>,
> Cecil Westerhof <Ce...@decebal.nl> wrote:
>>jornws...@xs4all.nl (Oscar) writes:
>>
>>> In article <87cz5aq...@munus.decebal.nl>,
>>> Cecil Westerhof <Ce...@decebal.nl> wrote:
>>>>Wanneer ik die mount in nemo zie ik:
>>>
>>> Wat is nemo voor een ding?
>>
>>Een file manager die ik in xfce4 gebruik omdat thunar een aantal
>>'problemen' geeft.
>> https://en.wikipedia.org/wiki/Nemo_(file_manager)
>
> Oh, ken ik allemaal niet zo. Maar heeft nemo zijn eigen Android
> ondersteuning of maakt die gewoon gebruik van de onderliggende mount van
> het systeem, waar jij met rsync tegenaan praat?
andere manier dan rsync.
Nemo gebruikt:
mtp://LENOVO_Lenovo_TB-8705F_HA141AZC/
Terwijl rsync gebruikt:
/run/user/1000/gvfs/mtp:host=LENOVO_Lenovo_TB-8705F_HA141AZC/
Ik kan straks ook weleens kijken wat thunar gebruikt. Ik neem aan
hetzelfde als nemo, maar het kan geen kwaad om het te checken.
Cecil Westerhof
Mar 30, 2023, 9:44:03 AM3/30/23
to
Ik geef in:
/run/user/1000/gvfs/mtp:host=LENOVO_Lenovo_TB-8705F_HA141AZC/Internal shared storage/Documents/Old
Het commando:
rsync -rv ~/Documents/Lenova/Documents/Old/ .
En dit levert op:
sending incremental file list
todo2.txt
rsync: [receiver] rename "/run/user/1000/gvfs/mtp:host=LENOVO_Lenovo_TB-8705F_HA141AZC/Internal shared storage/Documents/Old/.todo2.txt.csGp1D" -> "todo2.txt": Input/output error (5)
sent 1,740 bytes received 35 bytes 3,550.00 bytes/sec
total size is 1,632 speedup is 0.92
Thunar kijkt op dezelfde plek als nemo.
/run/user/1000/gvfs/mtp:host=LENOVO_Lenovo_TB-8705F_HA141AZC/Internal shared storage/Documents/Old
Het commando:
rsync -rv ~/Documents/Lenova/Documents/Old/ .
En dit levert op:
sending incremental file list
todo2.txt
rsync: [receiver] rename "/run/user/1000/gvfs/mtp:host=LENOVO_Lenovo_TB-8705F_HA141AZC/Internal shared storage/Documents/Old/.todo2.txt.csGp1D" -> "todo2.txt": Input/output error (5)
sent 1,740 bytes received 35 bytes 3,550.00 bytes/sec
total size is 1,632 speedup is 0.92
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1333) [sender=3.2.3]
Het lijkt wel of het erger wordt.
Thunar kijkt op dezelfde plek als nemo.
Oscar
Mar 30, 2023, 9:49:23 AM3/30/23
to
In article <87h6u2j...@munus.decebal.nl>,
"echte" mount onder /run/user/...
Hoe mount je die laatste? Of doet/nemo/gnome/dbus/whatever dat voor jou
op het moment dat je die mtp:// link benadert?
Cecil Westerhof <Ce...@decebal.nl> wrote:
>Nemo gebruikt:
> mtp://LENOVO_Lenovo_TB-8705F_HA141AZC/
>
>Terwijl rsync gebruikt:
> /run/user/1000/gvfs/mtp:host=LENOVO_Lenovo_TB-8705F_HA141AZC/
Ik gok dat mtp:// een door Nemo ondersteunde shortcut is voor die
>Nemo gebruikt:
> mtp://LENOVO_Lenovo_TB-8705F_HA141AZC/
>
>Terwijl rsync gebruikt:
> /run/user/1000/gvfs/mtp:host=LENOVO_Lenovo_TB-8705F_HA141AZC/
"echte" mount onder /run/user/...
Hoe mount je die laatste? Of doet/nemo/gnome/dbus/whatever dat voor jou
op het moment dat je die mtp:// link benadert?
Oscar
Mar 30, 2023, 9:59:25 AM3/30/23
to
In article <878rfej...@munus.decebal.nl>,
Nu is het niet meer de call 'mkstemp' die de foutmelding geeft. Die ging
goed en er hoefde ook geen andere attributen meer aangepast te worden.
Maar nu gaat 'rename' fout. Kun je nog eens lezen wat ik schreef bij je
poging tot "mv todo.txt todo2.txt" ? Ik veronderstelde dat dit FS geen
rename() ondersteunt. En ja hoor... het gaat fout als rsync na de
transfer een rename() doet om het tijdelijke bestand de definitieve naam
te geven.
>Het lijkt wel of het erger wordt.
Nee hoor, we zijn al een stap verder.
Kan het zijn dat .todo2.txt.RANDOM nu wel een inhoud heeft?
<gaat even in de manual van rsync zoeken>
probeer eens:
rsync -rv -T /tmp <source> <dest>
Bij deze actie wordt de tijdelijke file in /tmp aangemaakt en wordt
daarna over de destination heen gekopieerd. Niet heel nuttig bij een
lokale transfer, maar rsync was ooit bedoeld voor trage verbindingen.
Een nadeel heb je nu wel: de rename() is atomair, waar copy/delete dat
niet is. Als je niet weet waarom dat belangrijk is, heb je het
waarschijnlijk niet nodig.
Cecil Westerhof <Ce...@decebal.nl> wrote:
>jornws...@xs4all.nl (Oscar) writes:
>
>> TL;DR: probeer eens rsync -rv ... ipv rscync -av ...
>
>Ik geef in:
> /run/user/1000/gvfs/mtp:host=LENOVO_Lenovo_TB-8705F_HA141AZC/Internal shared storage/Documents/Old
>
>Het commando:
> rsync -rv ~/Documents/Lenova/Documents/Old/ .
>
>En dit levert op:
> sending incremental file list
> todo2.txt
> rsync: [receiver] rename "/run/user/1000/gvfs/mtp:host=LENOVO_Lenovo_TB-8705F_HA141AZC/Internal shared storage/Documents/Old/.todo2.txt.csGp1D" ->
>"todo2.txt": Input/output error (5)
Aha!
>jornws...@xs4all.nl (Oscar) writes:
>
>> TL;DR: probeer eens rsync -rv ... ipv rscync -av ...
>
>Ik geef in:
> /run/user/1000/gvfs/mtp:host=LENOVO_Lenovo_TB-8705F_HA141AZC/Internal shared storage/Documents/Old
>
>Het commando:
> rsync -rv ~/Documents/Lenova/Documents/Old/ .
>
>En dit levert op:
> sending incremental file list
> todo2.txt
> rsync: [receiver] rename "/run/user/1000/gvfs/mtp:host=LENOVO_Lenovo_TB-8705F_HA141AZC/Internal shared storage/Documents/Old/.todo2.txt.csGp1D" ->
>"todo2.txt": Input/output error (5)
Nu is het niet meer de call 'mkstemp' die de foutmelding geeft. Die ging
goed en er hoefde ook geen andere attributen meer aangepast te worden.
Maar nu gaat 'rename' fout. Kun je nog eens lezen wat ik schreef bij je
poging tot "mv todo.txt todo2.txt" ? Ik veronderstelde dat dit FS geen
rename() ondersteunt. En ja hoor... het gaat fout als rsync na de
transfer een rename() doet om het tijdelijke bestand de definitieve naam
te geven.
>Het lijkt wel of het erger wordt.
Kan het zijn dat .todo2.txt.RANDOM nu wel een inhoud heeft?
<gaat even in de manual van rsync zoeken>
probeer eens:
rsync -rv -T /tmp <source> <dest>
Bij deze actie wordt de tijdelijke file in /tmp aangemaakt en wordt
daarna over de destination heen gekopieerd. Niet heel nuttig bij een
lokale transfer, maar rsync was ooit bedoeld voor trage verbindingen.
Een nadeel heb je nu wel: de rename() is atomair, waar copy/delete dat
niet is. Als je niet weet waarom dat belangrijk is, heb je het
waarschijnlijk niet nodig.
Cecil Westerhof
Mar 30, 2023, 12:14:06 PM3/30/23
to
.todo2.txt.csGp1D.
> <gaat even in de manual van rsync zoeken>
>
> probeer eens:
>
> rsync -rv -T /tmp <source> <dest>
>
> Bij deze actie wordt de tijdelijke file in /tmp aangemaakt en wordt
> daarna over de destination heen gekopieerd. Niet heel nuttig bij een
> lokale transfer, maar rsync was ooit bedoeld voor trage verbindingen.
> Een nadeel heb je nu wel: de rename() is atomair, waar copy/delete dat
> niet is. Als je niet weet waarom dat belangrijk is, heb je het
> waarschijnlijk niet nodig.
ik thuis ben op de computer, dus dat gaat geen problemen opleveren
lijkt me.
Waar ik wel aan moet denken dat ik op slechts een plek de bestanden
aanpas en op het moment dat ik wil wisselen ik eerst een (goede) rsync
draai. Maar dat is een stukje discipline. En misschien kan het geen
kwaad om een slim scriptje hiervoor te schrijven.
Cecil Westerhof
Mar 30, 2023, 12:44:03 PM3/30/23
to
jornws...@xs4all.nl (Oscar) writes:
>>Als ik geef:
>> mv todo.txt todo2.txt
>>
>>Dan krijg ik:
>> mv: cannot move 'todo.txt' to 'todo2.txt': Input/output error
>>
>>Dan bevat $? ook 1 en in dit geval is de mv ook daadwerkelijk niet
>>uitgevoerd.
>
> Jemig, kan dat filesystem ook al niet renamen? Een mv binnen dezelfde
> mount wordt immers uitgevoerd met de rename(2) systemcall.
En als ik doe:
>>Als ik geef:
>> mv todo.txt todo2.txt
>>
>>Dan krijg ik:
>> mv: cannot move 'todo.txt' to 'todo2.txt': Input/output error
>>
>>Dan bevat $? ook 1 en in dit geval is de mv ook daadwerkelijk niet
>>uitgevoerd.
>
> Jemig, kan dat filesystem ook al niet renamen? Een mv binnen dezelfde
> mount wordt immers uitgevoerd met de rename(2) systemcall.
mv ~/Documents/Lenova/Documents/Old/file2move .
Dan krijg ik:
mv: preserving times for './file2move': Operation not supported
mv: preserving permissions for ‘./file2move’: Operation not supported
$? bevat 0 en het bestand is wel verplaatst.
Misschien moet ik een draadje op Debian beginnen.
Cecil Westerhof
Mar 30, 2023, 12:44:03 PM3/30/23
to
zichtbaar en als ik daar op klik wordt bij beide mtp:// geopend. Maar
ik kan in beide ook gewoon naar /run/user/ gaan.
0 new messages