Вы здесь

[SOLVED, ugly] python и samba/cifs

..вдруг откуда ни возьмись возникла необходимость средствами питона скопировать файл в cifs. Прилежно порывшись везде, где это имело смысл, не нашел ничего, кроме каких-то едва документированных 3rd party модулей. Очень надеюсь, что я просто ступил и не нашел. задача-то куда как совсем тривиальная...

вот какая получилась функция для копирования файла (враппер для smbclient). Заполнение и валидация dict CIFS происходит в парсере конфига
логирование для наглядности оставил

import subprocess, os

SMBCLT = '/usr/bin/smbclient'
CIFS = {'enabled': False, 'share': '', 'user': '', 'password': ''}

def CIFScopy(srcfile, dstfile=''):
    if CIFS['enabled']:
        if not dstfile: dst = os.path.basename(srcfile)
        else: dst = dstfile

        logger.info('CIFS copy. \'{0}\' -> \'{1}\''.format(srcfile, os.path.join(CIFS['share'], dst)))
        arg = [SMBCLT, CIFS['share']]
        if CIFS['password']:
            arg.append(CIFS['password'])
            arg.append('-U')
            arg.append(CIFS['user'])
        else:
            arg.append('-N')
            logger.debug('no password provided')

        arg.append('-c')
        arg.append('put \"{0}\" \"{1}\"'.format(srcfile, dst))
        logger.debug('starting copy')
        p = subprocess.Popen(arg, stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
        logger.info(p.communicate()[0].strip())
        if p.returncode == 0:
            logger.info('Successfully copied')
        else:
            logger.error('Error, return code ' + str(p.returncode))
    else:
        logger.debug('CIFS copy disabled')

Что значит в cifs? Шара куда-то примонтирована. Значит файл нужно записть в эту директорию.

а где сказано, что для чтения/записи конкретного файла нужна монтировка? вот тут, например, обходятся без монтировки

Beelzebubbie написал:
а где сказано, что для чтения/записи конкретного файла нужна монтировка? вот тут, например, обходятся без монтировки

монтировка она такая, весьма надо сказать многоцелевой инструмент, только вот осторожнее надо - а то и голову проломить ею можно...

Так и делай этим модулем, делов-то (-:Е

—

Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.

безусловно, отыскать _какой-либо_ способ это сделать не проблема, я хотел узнать, может есть более простой и нативный способ. Просто как-то трудно поверить - столько всего у питона в стандартной библиотеке, а самбы нет?

А за каким дьяволом она там? Это ж не ftp какой-нибудь, а сетевая файловая система. Поддержке файловой системы место в ядре ОС, а уж никак не в стандартной библиотеке ЯП.

—

Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.

а реализации этой поддержки не место в стд библиотеке? ))

Нет

—

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

ответ, безусловно, ясен и краток, но хотелось бы пояснений - почему?

Поддержку ext2 же никто не требует.

—

Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.

аналогия хромает, однако:
если у нас в системе есть поддержка extN, то мы можем библиотечными средствами осуществлять операции с файлами, расположенными на extN разделах, однако если у нас есть в ядре CIFS и в юзерспейсе samba - было бы логично иметь класс-враппер для операций с файлами, доступными через cifs. то есть аналог smbclient.
... а то приходится делать враппер уже для smbclient - уродливое решение, не так ли?

Beelzebubbie написал:
если у нас есть в ядре CIFS и в юзерспейсе samba…

То мы можем работать с файлами на smb.

—

Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.

Beelzebubbie написал:
то есть аналог smbclient.

Только вот smbclient`а в ядре нету. Это абсолютно "левая" приблуда. Это у вас с аналогией что-то...

а CONFIG_CIFS что тогда?

если у нас в системе есть поддержка extN, то мы можем библиотечными средствами осуществлять операции с файлами, расположенными на extN разделах, 

Чаго чаго ?
это какие такие операции с файлами при помощи библиотек от extN - fwrite(), fopen(), fclouse() что ли ?
Что то мне сдается, что ты путаешь уровень ФС и уровень доступа к файлу

—

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

File object из stdtypes. есть там и write и open и seek. это видимо и есть обертки для системного API или как он правильно называется
плюс shutils модуль еще есть - пожалуйста любые высокоуровневые операции. Я ессно себе отдаю отчет что это не только для extN FS но и для любых FS, для которых загружены модули и для которых реализован соответствующий интерфейс (или как он правильно называется).

Будто файлами на smb нельзя оперировать точно так же.

—

Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.

было бы можно - не создавал бы тему )

получается что есть 2 способа:
а) монтировать, производить действия, демонтировать
б) использовать свой враппер для smbclient (что я и сделал) или что-то вроде PySmbClient

если есть менее корявый способ, с удовольствием использую

По пункту «а» работают все остальные файловые системы. Чем CIFS лучше?

—

Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.

теоретически Вы правы (в плане поддержка FS -> монтирование -> работа стд методами) - с точки зрения _реализации_... т.е. (extN, fat, ntfs, cifs)

хотя практически (в аспекте данного топика) важнее разница между _локальными_ и _сетевыми_ ресурсами вне зависимости от техники их реализации. Я имею в виду, что локальные ресурсы (ФС) имеют как правило статическую конфигурацию (fstab и прочее). Я конечно, не могу судить, но ситуация "чтобы скопировать файл на локальное хранилище - авторизуемся, монтируем хранилище, копируем, демонтируем)" выглядит нереальной. На практике просто указывается путь к файлу (предполагается что все уже [авто]смонтировано), не так ли? (Я не рассматриваю экзотические ситуации)

Другое дело для сетевых ресурсов - там вовсе не предполагается постоянное подключение, следовательно схема другая - подключение/авторизация, копирование, отключение. Одинаково что для CIFS, что для HTTP что для FTP что для прочих способов. Причем возможны ситуации, что само понятие "монтирование" будет неприменимо в принципе (например доступен только конкретный URI, указывающий на файл, но не его контейнер)

Я имею в виду что монтирование как концепция способа управления локальным хранилищем данных совершенно очевидно не подходит для организации _произвольного_ доступа к сетевым ресурсам. Мы же сайты или почтовые сервера не монтируем?