M1k3 
@jeeynet regarde #rclone, ça fonctionne très bien de mon côté et prend en charge pas mal de protocoles, dont #SFTP. Tu peux même chiffrer ta sauvegarde.
SFTP : https://rclone.org/sftp/
AskUbuntu
Neustradamus :xmpp: :linux:#FileZilla 3.69.0 has been released (#libfilezilla / #FTP / #FTPS / #SFTP / #FTPClient / #FTPSClient / #SFTPClient) https://filezilla-project.org/
#curl 8.13.0 has been released (#libcurl / #Haxx / #DICT / #FILE / #FTP / #FTPS / #Gopher / #HTTP / #HTTPS / #IMAP / #IMAPS / #LDAP / #LDAPS / #MQTT / #POP3 / #POP3S / #RTMP / #RTMPS / #RTSP / #SCP / #SFTP / #SMB / #SMBS / #SMTP / #SMTPS / #Telnet / #TFTP / #WebSocket / #SOCKS4 / #SOCKS5 / #SCRAM / #TLS / #HTTP2 / #HTTP3) https://curl.se/
Terence EdenHey Linux friends. Is there a better graphical FTP program than Filezilla?
I'm finding Filezilla to be increasingly buggy, and I need something I can use with drag & drop & synchronised browsing.
What's a good replacement that you've *personally* used?
(Anyone telling me to use the command-line will be fired into a dark pit of scorpions. The scorpions have already eaten the people who say "here's the first result from a search query.")
MikeFTrump seeks to end climate research at premier U.S. climate agency
White House aims to end NOAA’s research office; NASA also targeted
https://www.science.org/content/article/trump-seeks-end-climate-research-premier-u-s-climate-agency
#climatechange #climatejustice #defendscience #SftP #trump #maga #fascism #climatedenial #ecosocialism #xr
razzlom is always sadРаспробовал тут #hydrus. Давно хотел локальную буру, а альтернативы в виде клиент-серверного решения не очень нравились. К тому же #Shimmie не очень удобно пользоваться.
К этому прикрутил бэкапы базы с помощью #restic. Передаёт бэкапы по #sftp, есть снапшоты и дедупликация. Всё нравится. Надо будет это программулину прикрутить на #QuietBBS.
К этому прикрутил бэкапы базы с помощью #restic. Передаёт бэкапы по #sftp, есть снапшоты и дедупликация. Всё нравится. Надо будет это программулину прикрутить на #QuietBBS.
Giacomo TesioFurther down this rabbit hole.
Sorry for the noise, but the more I go deeper, the worse it looks like, and I need to vent to people who might understand.
The #SFTP specification version 3, section 7 actually provides the number of links of each file the "longname" of the SSH_FXP_NAME response:
The SSH_FXP_NAME response has the following format:
uint32 id
uint32 count
repeats count times:
string filename
string longname
ATTRS attrs
[...]
`longname' is an expanded format for the file name, similar to what
is returned by "ls -l" on Unix systems
[...]
The format of the `longname' field is unspecified by this protocol.
It MUST be suitable for use in the output of a directory listing
command (in fact, the recommended operation for a directory listing
command is to simply display this data).
So far so good: we should have the info we need (at least from unix servers) despite in an unfortunate textual format.
The specification also states that such long name MUST not be parsed and clients should rely on the binary attributes that follow, except that the same specification forgot to include st_nlink (maybe because not all operating system supports such info).
However let assume that we ignore that argument and patch sshfs to read and parse such text just to provide the proper st_nlink.
Will #OpenSSH properly implement the specification?
NO! It doesn't! 😭
Let's give it a try:
sftp> cd test
sftp> ls -l
-rw-r--r-- 2 tesio users 0 Mar 26 20:34 copy
-rw-r--r-- 2 tesio users 0 Mar 26 20:34 file
sftp> ls -l *
-rw-r--r-- ? 115209 100 0 Mar 26 21:34 copy
-rw-r--r-- ? 115209 100 0 Mar 26 21:34 file
It turns out that the sftp-server from OpenSSH handles
In the first case (no argument) the request comply to the specification.
In the second, it does not, apparently for no reason (the
So to properly fill
And we are talking about OpenSSH!
Guys... I wanna cry.
CC: @rozenglass@fedi.dreamscape.link @grunfink@comam.es @khm@hj.9fs.net @Velveteen@labyrinth.zone
Sorry for the noise, but the more I go deeper, the worse it looks like, and I need to vent to people who might understand.
The #SFTP specification version 3, section 7 actually provides the number of links of each file the "longname" of the SSH_FXP_NAME response:
The SSH_FXP_NAME response has the following format:
uint32 id
uint32 count
repeats count times:
string filename
string longname
ATTRS attrs
[...]
`longname' is an expanded format for the file name, similar to what
is returned by "ls -l" on Unix systems
[...]
The format of the `longname' field is unspecified by this protocol.
It MUST be suitable for use in the output of a directory listing
command (in fact, the recommended operation for a directory listing
command is to simply display this data).
So far so good: we should have the info we need (at least from unix servers) despite in an unfortunate textual format.
The specification also states that such long name MUST not be parsed and clients should rely on the binary attributes that follow, except that the same specification forgot to include st_nlink (maybe because not all operating system supports such info).
However let assume that we ignore that argument and patch sshfs to read and parse such text just to provide the proper st_nlink.
Will #OpenSSH properly implement the specification?
NO! It doesn't! 😭
Let's give it a try:
sftp> cd test
sftp> ls -l
-rw-r--r-- 2 tesio users 0 Mar 26 20:34 copy
-rw-r--r-- 2 tesio users 0 Mar 26 20:34 file
sftp> ls -l *
-rw-r--r-- ? 115209 100 0 Mar 26 21:34 copy
-rw-r--r-- ? 115209 100 0 Mar 26 21:34 file
It turns out that the sftp-server from OpenSSH handles
ls -l differently when it is received without any argument or with an argument.In the first case (no argument) the request comply to the specification.
In the second, it does not, apparently for no reason (the
ls_file function receives remote = 1).So to properly fill
st_nlink in #sshfs, for any file we should sent an additional SSH_FXP_READDIR request to the server for the parent directory, find our file of interest within the list of files and extract the number of links from its longname.And we are talking about OpenSSH!
Guys... I wanna cry.
CC: @rozenglass@fedi.dreamscape.link @grunfink@comam.es @khm@hj.9fs.net @Velveteen@labyrinth.zone
Went a little down this rabbit hole and wrote an update to that issue and the related one on st_nlink.
The problem is not caused by #sshfs (or by the #fuse library), but by the #SFTP protocol itself that doesn't provide access to the underlying inode and provides access to the number of links only from version 06 while most server implementations (including #OpenSSH) are based on version 02.
Sad to see that in 2016 a developer contributed to OpenSSH a patch to provide such info as an extension attribute (a mechanism available at that protocol version) but the patch was not accepted (or, apparently, considered).
CC: @grunfink@comam.es @khm@hj.9fs.net @Velveteen@labyrinth.zone
The problem is not caused by #sshfs (or by the #fuse library), but by the #SFTP protocol itself that doesn't provide access to the underlying inode and provides access to the number of links only from version 06 while most server implementations (including #OpenSSH) are based on version 02.
Sad to see that in 2016 a developer contributed to OpenSSH a patch to provide such info as an extension attribute (a mechanism available at that protocol version) but the patch was not accepted (or, apparently, considered).
CC: @grunfink@comam.es @khm@hj.9fs.net @Velveteen@labyrinth.zone
∂𑁨í 🕊 