[Crosspost naar nl.comp.os.linux.techniek]
Post by Cecil WesterhofPost by OscarWat 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?
Post by Cecil WesterhofPost by OscarPost by Cecil Westerhofrsync: [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.
Post by Cecil WesterhofPost by OscarPost by Cecil Westerhofrsync 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.
Post by Cecil WesterhofPost by OscarPost by Cecil WesterhofWat 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?
Post by Cecil WesterhofPost by OscarHet 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.
Post by OscarDe 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.
Post by Cecil WesterhofPost by OscarSowieso 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.
Post by Cecil Westerhoftouch dummy
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.
Post by Cecil Westerhof-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.
Post by Cecil WesterhofEen '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!"
Post by Cecil Westerhofmv todo.txt todo2.txt
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:
***@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...
Post by Cecil WesterhofHet 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.
Post by Cecil Westerhofgvfsd-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 ...
--
[J|O|R] <- .signature.gz